\begin{aosachapter}{Thousand Parsec}{s:thousandparsec}{Alan Laudicina and Aaron Mavrinac}
%% Based on EN-Revision r272

%% A vast star empire encompasses a hundred worlds, stretching a thousand
%% parsecs across space. Unlike some other areas of the galaxy, few
%% warriors live here; this is an intellectual people, with a rich
%% cultural and academic tradition. Their magnificent planets, built turn
%% by turn around great universities of science and technology, are a
%% beacon of light to all in this age of peace and prosperity. Starships
%% arrive from the vast reaches of the quadrant and beyond, bearing the
%% foremost researchers from far and wide. They come to contribute their
%% skills to the most ambitious project ever attempted by sentient
%% beings: the development of a decentralized computer network to connect
%% the entire galaxy, with all its various languages, cultures, and
%% systems of law.
広大なスターエンパイアには100の世界が存在し、1000パーセクにまたがって広がっている。
銀河の他の部分とは違って、ここには戦士はほとんどいない。
そこにいるのは知的な人々で、豊かな文化と教養を兼ね備えている。
彼らの住む惑星では科学や工学の大学が続々とうまれ、
この世代の平和と繁栄の象徴となっている。
象限を超えて遙か彼方から宇宙船がやってきて、一線級の研究者たちが隅々まで調査している。
彼らはその知識をいかして、これまでにない壮大なプロジェクトにとりかかる。
分散型のコンピューターネットワークを構築して銀河全体をひとつにするというプロジェクトだ。
さまざまな言語や文化、そして法体系をすべてひとつにつないでしまおうというのだ。

%% Thousand Parsec is more than a video game: it is a framework, with a
%% complete toolkit for building multiplayer, turn-based space empire
%% strategy games. Its generic game protocol allows diverse
%% implementations of client, server, and AI software, as well as a vast
%% array of possible games. Though its size
%% has made planning and execution challenging,
%% forcing contributors to walk a thin line between
%% excessively vertical and excessively horizontal development, it also
%% makes it a rather interesting specimen when discussing the
%% architecture of open source applications.
Thousand Parsecは単なるビデオゲームではない。
一種のフレームワークであり、マルチプレイヤー型でターン制の宇宙帝国戦略ゲームを
構築するための完全なツールキットを含む。汎用的なゲームプロトコルを使えば
さまざまな実装のクライアントやサーバーそしてAIソフトウェアを作れるし、
あらゆるゲームを作れるだろう。規模が規模だけに実際に計画を実行するのは大変だろうが、
オープンソースアプリケーションのアーキテクチャについて議論するには興味深いものになる。

%% The journalist's label for the genre Thousand Parsec games inhabit is
%% ``4X''---shorthand for ``e\emph{x}plore, e\emph{x}pand,
%% e\emph{x}ploit, and e\emph{x}terminate,'' the modus operandi of the
%% player controlling an empire\footnote{Some excellent commercial
%% examples of Thousand Parsec's inspiration include \emph{VGA Planets}
%% and \emph{Stars!}, as well as the \emph{Master of Orion},
%% \emph{Galactic Civilizations}, and \emph{Space Empires} series. For
%% readers unfamiliar with these titles, the \emph{Civilization} series
%% is a popular example of the same gameplay style, albeit in a
%% different setting. A number of real-time 4X games also exist, such
%% as \emph{Imperium Galactica} and \emph{Sins of a Solar Empire}.}.
%% Typically in the 4X genre of games, players will scout to reveal the
%% map (explore), create new settlements or extend the influence of
%% existing ones (expand), gather and use resources in areas they control
%% (exploit), and attack and eliminate rival players (exterminate). The
%% emphasis on economic and technological development, micromanagement,
%% and variety of routes to supremacy yield a depth and complexity of
%% gameplay unparalleled within the greater strategy genre.
Thousand Parsecのようなゲームは、ジャーナリストに言わせると``4X''
(``e\emph{x}plore, e\emph{x}pand, e\emph{x}ploit, and e\emph{x}terminate''の略)
というジャンルらしい。プレイヤーが帝国をコントロールするものだ
\footnote{Thousand Parsecの発想の元になった、すばらしい商用ゲームの例がある。
\emph{VGA Planets}や\emph{Stars!}、そして\emph{Master of Orion}や
\emph{Galactic Civilizations}や\emph{Space Empires}シリーズなどである。
どれもあまりなじみのない人がいるかもしれない。では\emph{Civilization}シリーズならどうだろう。
これも同じスタイルのゲームだが、設定が少し異なる。リアルタイム型の4Xゲームもいろいろあって、
たとえば\emph{Imperium Galactica}や\emph{Sins of a Solar Empire}がその一例だ。}。
一般的な4X系のゲームでは、プレイヤーたちが地図を探し(explore)、
新たな協定を結んだり既存の協定の効力を拡張したり(expand)、
自分たちでコントロールできる資源を活用したり(exploit)して、
ライバルのプレイヤーたちを攻撃して滅亡させる(exterminate)。
経済成長や技術開発の重視、マイクロマネージメント、そしていろんなルートの優位性などによって、
このジャンルで他に類を見ない深みと複雑さを生み出した。

%% From a player's perspective, three main components are involved
%% in a game of Thousand Parsec. First, there is the client: this is the
%% application through which the player interacts with the universe. This
%% connects to a server over the network---communicating using the
%% all-important protocol---to which other players' (or, in some cases,
%% artificial intelligence) clients are also connected. The server stores
%% the entire game state, updating clients at the start of each turn.
%% Players can then perform various actions and communicate them back to
%% the server, which computes the resulting state for the next turn. The
%% nature of the actions a player may perform is dictated by a ruleset:
%% this in essence defines the game being played, implemented and
%% enforced on the server side, and actualized for the player by any
%% supporting client.
プレイヤーの視点でとらえると、三つの主要なコンポーネントがThousand Parsecのゲームにかかわることになる。
まず最初がクライアント。プレイヤーがゲームの世界とのやりとりをするアプリケーションだ。
クライアントはネットワーク越しに(あらゆる重要なプロトコルを用いて)サーバーに接続する。他のプレイヤー
(場合によっては人工知能)のクライアントもそこに接続している。
そしてサーバー。サーバーでは全体的なゲームの状態を管理し、各ターンの開始時にクライアントを更新する。
プレイヤーはさまざまなアクションを行い、それをサーバーに返す。
サーバーでは、その結果を計算して次のターンに備える。
そして最後がルールセット。
プレイヤーが行うアクションの性質はルールセットによって決まる。
突き詰めると、このルールセットがゲームを定義することになる。
これはサーバー側で実装するもので、
それをサポートするクライアントによってプレイヤー側で実現する。

%% Because of the diversity of possible games, and the complexity of the
%% architecture required to support this diversity, Thousand Parsec is an
%% exciting project both for gamers and for developers. We hope that even
%% the serious coder with little interest in the anatomy of game
%% frameworks might find value in the underlying mechanics of
%% client-server communication, dynamic configuration, metadata handling,
%% and layered implementation, all of which have grown rather organically
%% toward good design over the years in quintessential open source style.
さまざまなゲームが作られるだろうし、その多様性に対応するだけの複雑なアーキテクチャが必要となる。
Thousand Parsecは、ゲーマーだけでなく開発者にとってもエキサイティングなプロジェクトだ。
ゲームのフレームワークの仕組みになんか興味がないというまじめな開発者さんたちにも、
ぜひそのおもしろさを知っていただきたい。その裏側で動いているクライアント・サーバー通信や
動的な構成、メタデータの処理、レイヤー化した実装など、これらすべてが長年をかけて
有機的に成長してきた。典型的なオープンソーススタイルでだ。

%% At its core, Thousand Parsec is primarily a set of standard
%% specifications for a game protocol and other related
%% functionality. This chapter discusses the framework mostly from this
%% abstract viewpoint, but in many cases it is much more enlightening
%% to refer to actual implementations. To this end, the authors have
%% chosen the ``flagship'' implementations of each major component for
%% concrete discussion.
本質的には、そもそもThousand Parsecはゲームのプロトコルやその他関連機能に関する標準仕様群である。
本章の大半は、この視点でとらえたフレームワークについて議論する。
しかし、実際の実装を参照したほうがずっとわかりやすい場合も多い。
そのために私たちは、主要コンポーネントのそれぞれについて「フラッグシップ」実装を選び、
それを使って具体的な議論をすることにした。

%% The case model client is \code{tpclient-pywx}, a relatively mature
%% wxPython-based client which at present supports the largest set of
%% features and the latest game protocol version. This is supported by
%% \code{libtpclient-py}, a Python client helper library providing
%% caching and other functionality, and \code{libtpproto-py}, a Python
%% library which implements the latest version of the Thousand Parsec
%% protocol. For the server, \code{tpserver-cpp}, the mature C++
%% implementation supporting the latest features and protocol version, is
%% the specimen. This server sports numerous rulesets, among which the
%% \emph{Missile and Torpedo Wars} milestone ruleset is exemplary for
%% making the most extensive use of features and for being a
%% "traditional" 4X space game.
モデルとなるクライアントは\code{tpclient-pywx}だ。
これは比較的成熟したwxPythonベースのクライアントで、
現時点では最も多くの機能をサポートしており、最新バージョンのゲームプロトコルにも対応している。
このクライアントは\code{libtpclient-py}によってサポートされている。
これはPythonのクライアントヘルパーライブラリで、キャッシュなどの機能を提供する。
また、Pythonのライブラリ\code{libtpproto-py}は最新バージョンのThousand Parsecプロトコルを実装している。
サーバーには\code{tpserver-cpp}。これも歴史のあるC++の実装で、
最新の機能やプロトコルに対応している。これを見本として採用する。
このサーバーはさまざまなルールセットに対応しているが、中でも
マイルストーンルールセット\emph{Missile and Torpedo Wars}
は、「伝統的な」4X宇宙ゲームを実装するためのよい見本となる。

%% \begin{aosasect1}{Anatomy of a Star Empire}
\begin{aosasect1}{スターエンパイアの世界}

%% In order to properly introduce the things that make up a Thousand
%% Parsec universe, it makes sense first to give a quick overview of a
%% game. For this, we'll examine the \emph{Missile and Torpedo Wars}
%% ruleset, the project's second milestone ruleset, which makes use of
%% most of the major features in the current mainline version of the
%% Thousand Parsec protocol. Some terminology will be used here which
%% will not yet be familiar; the remainder of this section will elucidate
%% it so that the pieces all fall into place.
Thousand Parsecの世界を構成するものごとを適切に紹介するために、
まずこのゲームの概要を説明しよう。ここでは
\emph{Missile and Torpedo Wars}ルールセットを見ていく。
このルールセットはプロジェクトの二番目のマイルストーンルールセットで、
現在の安定版Thousand Parsecプロトコルにある主要な機能のほとんどを使っている。
あまりなじみのない用語もいくつか登場するが、それらは追々解説していくので
理解してもらえるだろう。

%% \emph{Missile and Torpedo Wars} is an advanced ruleset in that it
%% implements all of the methods available in the Thousand Parsec
%% framework. At the time of writing, it is the only ruleset to do so,
%% and it is being quickly expanded to become a more complete and
%% entertaining game.
\emph{Missile and Torpedo Wars}は上級者向けのルールセットで、
Thousand Parsecフレームワークで使えるすべてのメソッドを実装している。
本章の執筆時点ではそんなルールセットはこれだけしかない。
また、手早く拡張し、より完全な楽しいゲームになった。

%% Upon establishing a connection to a Thousand Parsec server, the client
%% probes the server for a list of game entities and proceeds to download
%% the entire catalog.  This cataloger includes all of the objects,
%% boards, messages, categories, designs, components, properties, players,
%% and resources that make up the state of the game, all of which are
%% covered in detail in this section. While this may seem like a lot for
%% the client to digest at the beginning of the game---and also at the
%% end of each turn---this information is absolutely vital for the
%% game. Once this information has been downloaded, which generally takes on the order of a few seconds, the client now has
%% everything it needs to plot the information onto its representation of
%% the game universe.
Thousand Parsecサーバーとの接続を確立するときに、
クライアントはゲームエンティティの一覧を調べて全カタログをダウンロードする。
このカタログにはすべてのオブジェクトやボード、メッセージ、カテゴリ、デザイン、
コンポーネント、プロパティ、プレイヤー、そしてゲームの状態を形作る資源が含まれている。
これらの詳細については後ほど詳述する。ゲームを始めるときにクライアント側で知るべきことが
大量にあるように見える(各ターンの終了時も同様だ)が、
これらの情報はどれもゲームに不可欠なものである。
この情報をダウンロードし終えるには数秒程度かかるが、
これでクライアントに必要な情報はすべてそろい、
ゲームの世界を表現できるようになる。

%% When first connected to the server, a random planet is generated and
%% assigned as the new player's ``home planet'', and two fleets are
%% automatically created there. Each fleet consists of two default Scout
%% designs, consisting of a Scout Hull with an Alpha Missile Tube.  Since
%% there is no Explosive component added, this default fleet is not yet
%% capable of fleet-to-fleet or fleet-to-planet combat; it is, in fact, a
%% sitting duck.
最初にサーバーに接続したときにランダムに惑星が作られ、それが新しいプレイヤーの
「母星」となる。そして、その母星には自動的にふたつの艦隊が配備される。
各艦隊はふたつのScoutデザイン(デフォルトのデザイン)で構成されており、
Scout HullとAlpha Missile Tubeを持っている。
Explosiveコンポーネントが追加されていないので、デフォルトの艦隊はこのままでは
対艦隊戦や対惑星戦ができない。要するに、まったく無防備な状態だ。

%% \pagebreak

%% At this point, it is important for a player to begin equipping fleets
%% with weaponry. This is achieved by creating a weapon design using a
%% Build Weapon order, and then loading the finished product onto the
%% target fleet through a Load Armament order. The Build Weapon order
%% converts a planet's resources---of which each planet has amounts and
%% proportions assigned by a random distribution---into a finished
%% product: an explosive warhead which is planted on the creating
%% planet's surface. The Load Armament order then transfers this
%% completed weapon onto a waiting fleet.
この時点でプレイヤーがすべきことは、まず艦隊の武装を始めることだ。
Build Weapon命令を使って兵器を設計して、できあがった製品を
Load Armament命令で艦隊に搭載する。
Build Weapon命令は、惑星の資源
---各惑星には、資源がランダムに割り当てられている---
を製品に変換する。爆発性の弾頭で、これを惑星の地表で生産するわけだ。
Load Armament命令は、完成した製品を艦隊に転送する。

%% Once the easily accessible surface resources of a planet are used up,
%% it is important to obtain more through mining. Resources come in two
%% other states: mineable and inaccessible. Using a Mine order on a
%% planet, mineable resources may be converted over time into surface
%% resources, which can then be used for building.
惑星の地表にある資源を使い切ってしまったら、
新たな資源を得るための採掘が重要になる。
資源には、地表にある状態以外に二種類の状態がある。採掘可能(mineable)とアクセス不能(inaccessible)だ。
Mine命令を惑星上で実行すると、採掘可能な資源を地表の資源に変換する。
これにはある程度の時間がかかり、地表の資源になれば実際に使えるようになる。

%% \begin{aosasect2}{Objects}
\begin{aosasect2}{オブジェクト}

%% In a Thousand Parsec universe, every physical thing is an object. In
%% fact, the universe itself is also an object. This design allows for a
%% virtually unlimited set of elements in a game, while remaining simple
%% for rulesets which require only a few types of objects. On top of the
%% addition of new object types, each object can store some of its own
%% specific information that can be sent and used via the Thousand Parsec
%% protocol. Five basic built-in object types are currently provided by
%% default: Universe, Galaxy, Star System, Planet, and Fleet.
Thousand Parsecの世界では、形を持つものはすべてオブジェクトとなる。
実際、その世界自体もまたオブジェクトだ。
このように設計したおかげで、事実上無限の要素をゲームに含めることができるようになり、
いくらオブジェクトを増やしたところでその一部しか使わないルールセットはシンプルなままに保てるようになった。
新たなオブジェクト型を追加すると、それに固有の情報を格納できるようになる。
そしてそれを、Thousand Parsecプロトコルで送信したり使ったりできるというわけだ。
現在デフォルトで提供されている基本的なオブジェクト型は
Universe、Galaxy、Star System、Planet、そしてFleetの五つである。

%% The Universe is the top-level object in a Thousand Parsec game, and it
%% is always accessible to all players. While the Universe object does
%% not actually exert much control over the game, it does store one
%% vastly important piece of information: the current turn number. Also
%% known as the ``year'' in Thousand Parsec parlance, the turn number,
%% naturally, increments after the completion of each turn. It is stored
%% in an unsigned 32-bit integer, allowing for games to run until year
%% 4,294,967,295. While not impossible in theory, the authors have not,
%% to date, seen a game progress this far.
UniverseはThousand Parsecのゲームの最上位にあるオブジェクトであり、全プレイヤーが常にアクセスできる。
Universeオブジェクト自体は実際のところゲーム全体を取り仕切るわけではなく、
非常に重要なたったひとつの情報、つまり現在のターン番号を格納している。
Thousand Parsecの世界ではターン番号のことを``year''と呼んでおり、
ターンが終わるごとにひとつずつ増えていく。符号なし32ビット整数で格納されるので、
4,294,967,295年までゲームを続けることができる。
ただ、理屈上ではそうだが、作者は実際にゲームがそこまで進むのを見たことはない。

%% A Galaxy is a container for a number of proximate objects---Star
%% Systems, Planets and Fleets---and provides no additional
%% information. A large number of Galaxies may exist in a game, each
%% hosting a subsection of the Universe.
Galaxyは、近くにあるオブジェクト(Star SystemやPlanet、Fleet)
をとりまとめるコンテナで、それ以外に特別な情報を提供するわけではない。
一つのゲームの中には多数のGalaxyが存在することがあり、それぞれがUniverse
の一部を構成する。

%% Like the previous two objects, a Star System is primarily a container
%% for lower-level objects. However, the Star System object is the first
%% tier of object which is represented graphically by the client. These
%% objects may contain Planets and Fleets (at least temporarily).
これら二つのオブジェクトと同様に、Star Systemもその主目的は下位レベルのオブジェクトのコンテナとなることだ。
ただ、Star Systemオブジェクトはクライアントに表示されるオブジェクトの最初の層となる。
このオブジェクトの中には、(少なくとも一時的には)PlanetやFleetが含まれることになる。

%% A Planet is a large celestial body which may be inhabited and provide
%% resource mines, production facilities, ground-based armaments, and
%% more. The Planet is the first tier of object which can be owned by a
%% player; ownership of a Planet is an accomplishment not to be taken
%% lightly, and not owning any planets is a typical condition for
%% rulesets to proclaim a player's defeat. The Planet object has a
%% relatively large amount of stored data, accounting for the following:
Planetは大きな天体で、人が住んだり資源を採掘したり設備を生産したり
地上軍を配備したりといったことができる。
Planetは、プレイヤーが所有できるオブジェクトの最初の層である。
あるPlanetを所有するというのは気軽にできることではない。
たいていのルールセットでは、ひとつもPlanteを持っていないということは
そのプレイヤーが敗北したことを意味する。
Planetオブジェクトには比較的大量のデータが格納される。次のようなものだ。

\begin{aosaitemize}

  %% \item The player ID of the Planet's owner (or -1 if not owned by any
  %% player).
  \item そのPlanetの所有者のプレイヤーID(所有者がいない場合は-1)。

  %% \item A list of the Planet's resources, containing the resource ID
  %% (type), and the amount of surface, mineable, and inaccessible
  %% resources of this type on the Planet.
  \item そのPlanetの資源の一覧。資源ID(型)と、そのPlanetにおける地表資源・採掘可能資源・アクセス不能資源の量。

\end{aosaitemize}

%% The built-in objects described above provide a good basis for many
%% rulesets following the traditional 4X space game formula. Naturally,
%% in keeping with good software engineering principles, object classes
%% can be extended within rulesets. A ruleset designer thus has the
%% ability to create new object types or store additional information in
%% the existing object types as required by the ruleset, allowing for
%% virtually unlimited extensibility in terms of the available physical
%% objects in the game.
これまでに取り上げた組み込みのオブジェクト群を使えば、伝統的な
4X型宇宙ゲームに沿った多くのルールセットにとっての十分な基盤となる。
当然ながら、ソフトウェア工学の原則に従って、これらのオブジェクトのクラスをルールセット内で
拡張することもできる。つまりルールセットを作る人は、
新たなオブジェクト型を作ることもできるし既存のオブジェクト型に追加情報を持たせることもできるというわけだ。
ゲーム内に登場するあらゆるオブジェクトについて、事実上無制限に拡張できることになる。

\end{aosasect2}

%% \begin{aosasect2}{Orders}
\begin{aosasect2}{命令}

%% Defined by each ruleset, orders can be attached to both Fleet and
%% Planet objects. While the core server does not ship with any default
%% order types, these are an essential part of even the most basic
%% game. Depending on the nature of the ruleset, orders may be used to
%% accomplish almost any task. In the spirit of the 4X genre, there are a
%% few standard orders which are implemented in most rulesets: these are
%% the Move, Intercept, Build, Colonize, Mine, and Attack orders.
命令はルールセットが定義するもので、FleetオブジェクトとPlanetオブジェクトにアタッチできる。
コアサーバーにはデフォルトの命令型は何も含まれていないが、どんなに基本的なゲームであっても命令は不可欠なものだ。
そのルールセットの性質に沿って、命令を使えばほぼあらゆるタスクを達成できる。
4X型のゲームではお決まりの命令がいくつかあって、それは大抵のルールセットに実装されている。
Move、Intercept、Build、Colonize、MineそしてAttackといった命令である。

%% In order to fulfill the first imperative (e\emph{x}plore) of 4X, one
%% needs to be able to move about the map of the universe. This is
%% typically achieved via a Move order appended to a Fleet object. In the
%% flexible and extensible spirit of the Thousand Parsec framework, Move
%% orders can be implemented differently depending on the nature of the
%% ruleset. In \emph{Minisec} and \emph{Missile and Torpedo Wars}, a Move
%% order typically takes a point in 3D space as a parameter. On the
%% server side, the estimated time of arrival is calculated and the
%% number of required turns is sent back to the client. The Move order
%% also acts as a pseudo-Attack order in rulesets where teamwork is not
%% implemented. For example, moving to a point occupied by an enemy fleet
%% in both Minisec and Missile and Torpedo Wars is almost certain to be
%% followed by a period of intense combat. Some rulesets supporting a Move
%% order parameterize it differently (i.e. not using 3D points). For
%% example, the \emph{Risk} ruleset only allows single-turn moves to
%% planets which are directly connected by a ``wormhole''.
4Xのうちの最初の任務(つまりe\emph{x}plore)をこなすには、
ゲーム世界のマップ上を移動できないといけない。これは一般に
Move命令の仕事で、この命令はFleetオブジェクトに追加されている。
Thousand Parsecフレームワークは柔軟で拡張性を重視しているので、
Move命令の実装もルールセットごとに変更できる。
\emph{Minisec}や\emph{Missile and Torpedo Wars}の場合、Move命令は
三次元空間上の座標をパラメータとして受け取る。サーバー側では
移動所要時間を計算し、必要なターン数をクライアントに返す。
ルールセットによっては、Move命令が疑似Attack命令として機能するものもある。
チーム作業が実装されていないようなルールセットでよくあることだ。
たとえばMinisecやMissile and Torpedo Warsの場合、
敵の艦隊が抑えている座標に移動するとそこで戦いが始まる。
ルールセットによっては、Move命令のパラメータが違っている
(つまり、三次元座標を使わない)ものもある。
たとえば\emph{Risk}ルールセットには1ターンでの移動しか存在しない。
「ワームホール」でつながった別の惑星に直接移動するというものだ。

%% Typically appended to Fleet objects, the Intercept order allows an
%% object to meet another (commonly an enemy fleet) within space. This
%% order is similar to Move, but since two objects might be moving in
%% different directions during the execution of a turn, it is impossible
%% to land directly on another fleet simply using spatial coordinates, so
%% a distinct order type is necessary. The Intercept order addresses this
%% issue, and can be used to wipe out an enemy fleet in deep space or
%% fend off an oncoming attack in a moment of crisis.
一般的にFleetオブジェクトに追加されることが多いIntercept命令は、
空間内の他のオブジェクト(たいていは敵艦隊)に遭遇させるために使うものだ。
Move命令と似ているが、実行している間にふたつのオブジェクトが別方向に移動する可能性もあるので、
単純に空間内の座標を指定するだけでは他の艦隊にぶつけるのは不可能だ。そこで、別の命令を用意する必要があった。
この問題に対応するために用意されたのがIntercept命令で、
これを使えば深宇宙にいる敵艦隊を一掃したり、危機的な状況で攻撃されるのをかわしたりできる。

%% The Build order helps to fulfill two of the 4X
%% imperatives---e\emph{x}pand and e\emph{x}ploit. The obvious means of
%% expansion throughout the universe is to build many fleets of ships and
%% move them far and wide. The Build order is typically appended to
%% Planet objects and is often bound to the amount of resources that a
%% planet contains---and how they are exploited. If a player is lucky
%% enough to have a home planet rich in resources, that player could gain
%% an early advantage in the game through building.
Build命令は、4Xのうちの二つ(e\emph{x}pandとe\emph{x}ploit)に対応するものだ。
ゲーム世界で勢力を拡大していく手段として明白なのは、大量の艦隊を編成してより遠方まで進出することだ。
Build命令はPlanetオブジェクトに追加されるのが一般的で、
たいていは、その惑星に存在する資源の量(そして採掘状況)による制約を受ける。
幸運にも資源に恵まれた母星を持っているプレイヤーは、
ゲームの初期段階で有利にたてる。

%% Like the Build order, the Colonize order helps fulfill the
%% e\emph{x}pand and e\emph{x}ploit imperatives. Almost always appended
%% to Fleet objects, the Colonize order allows the player to take over an
%% unclaimed planet. This helps to expand control over planets throughout
%% the universe.
Build命令と同様に、Colonize命令もe\emph{x}pandとe\emph{x}ploitを実行するためのものだ。
ほとんどの場合はFleetオブジェクトに追加される命令であり、
このColonize命令を使うと、まだ誰も領有権を宣言していない惑星を占領できる。
ゲーム世界の中で、自分の制御のおよぶ範囲を拡大するのに役立つだろう。

%% The Mine order embodies the e\emph{x}ploit imperative. This order,
%% typically appended to Planet objects and other celestial bodies,
%% allows the player to mine for unused resources not immediately
%% available on the surface. Doing so brings these resources to the
%% surface, allowing them to be used subsequently to build and ultimately
%% expand the player's grip on the universe.
Mine命令はe\emph{x}ploitのために使うものだ。この命令はPlanetオブジェクトあるいは
その他の天体オブジェクトに追加されるのが一般的で、
まだ地表にはない資源を採掘することができる。
採掘を実行すれば資源が地表に登場し、後でそれを使って開発をしたり、
ゲーム世界内でプレイヤーの手の届く範囲を広げたりする。

%% Implemented in some rulesets, the Attack order allows a player to
%% explicitly initiate combat with an enemy Fleet or Planet, fulfilling
%% the final 4X imperative (e\emph{x}terminate). In team-based rulesets,
%% the inclusion of a distinct Attack order (as opposed to simply using
%% Move and Intercept to implicitly attack targets) is important to avoid
%% friendly fire and to coordinate attacks.
いくつかのルールセットに実装されているAttack命令を使うと、
敵のFleetやPlanetとの戦闘を明示的に始めることができる。
これは、4Xの最後の任務すなわちe\emph{x}terminateを達成するためのものだ。
チームベースのルールセットでは、(MoveやInterceptで攻撃対象を指定して暗黙のうちに戦いを始めるのではなく)
Attack命令を別途用意しておくことが重要となる。
そうしないと、まちがって友軍との戦闘が始まってしまうことがあり得るからである。

%% Since the Thousand Parsec framework requires ruleset developers to
%% define their own order types, it is possible---even encouraged---for
%% them to think outside the box and create custom orders not found
%% elsewhere. The ability to pack extra data into any object allows
%% developers to do very interesting things with custom order types.
Thousand Parsecフレームワークでは、ルールセットの開発者が自分で命令の型を定義できるようにしているので、
どこにもないような斬新な命令を作ることもできる…というか、それが推奨されている。
追加のデータをあらゆるオブジェクトに組み込めるので、
開発者にとっては新たな命令を作るのはとてもおもしろいことだろう。

\end{aosasect2}

%% \begin{aosasect2}{Resources}
\begin{aosasect2}{資源}

%% Resources are extra pieces of data that are packed into Objects in the
%% game. Extensively used---particularly by Planet objects---resources
%% allow for easy extension of rulesets. As with many of the design
%% decisions in Thousand Parsec, extensibility was the driving factor in
%% the inclusion of resources.
資源は、ゲーム内のオブジェクトに組み込まれているデータのひとつである。
特にPlanetオブジェクトで幅広く使われており、これを使うと
ルールセットを簡単に拡張できる。Thousand Parsecの設計の多くがそうであったように、
資源という概念を含めたのも拡張性を考慮したためだ。

%% While resources are typically implemented by the ruleset designer,
%% there is one resource that is in consistent use throughout the
%% framework: the Home Planet resource, which is used to identify a
%% player's home planet.
資源を実装するのはルールセットを設計する人であることが多いが、
フレームワーク全体を通して一貫して使われる資源がひとつだけある。
それがHome Planetで、これはプレイヤーの母星を識別するために使われる。

%% According to Thousand Parsec best practices, resources are typically
%% used to represent something that can be converted into some type of
%% object. For example, Minisec implements a Ship Parts resource, which
%% is assigned in random quantities to each planet object in the
%% universe.  When one of these planets is colonized, you can then
%% convert this Ship Parts resource into actual Fleets using a Build
%% order.
Thousand Parsecのベストプラクティスに従うと、
資源の一般的な利用法は、何らかの型のオブジェクトに変換できる何かを表現することだ。
たとえばMinisecではShip Partsという資源を実装しており、
ゲーム世界のそれぞれのPlanetオブジェクトに対してランダムな量が割り当てられる。
どこかの惑星を占領すると、その惑星のShip Partsを使って
Build命令でFleetに変換することができる。

%% \emph{Missile and Torpedo Wars} makes perhaps the most extensive use
%% of resources of any ruleset to date. It is the first ruleset where the
%% weapons are of a dynamic nature, meaning that they can be added to a
%% ship from a planet and also removed from a ship and added back to a
%% planet. To account for this, the game creates a resource type for each
%% weapon that is created in the game. This allows ships to identify a
%% weapon type by a resource, and move them freely throughout the
%% universe. \emph{Missile and Torpedo Wars} also keeps track of
%% factories (the production capability of planets) using a Factories
%% resource tied to each planet.
\emph{Missile and Torpedo Wars}は、おそらく現時点で最も資源を活用しているルールセットだろう。
兵器を動的な資源として扱った最初のルールセットでもある。
これはつまり、惑星上にある兵器を船に追加したり、
逆に船に搭載していた兵器を惑星に戻したりできるということだ。
ゲーム内のそれぞれの兵器に対して新たな資源の型を用意し、
ゲーム内で資源を作るようにしたのだ。
これで、資源の型を指定して船上の兵器を特定したり、
ゲームの世界の中で兵器を自由に運べるようになった。
\emph{Missile and Torpedo Wars}では、工場(惑星上での生産施設)
についてもFactoriesという資源で管理しており、これを各惑星に結び付けている。

\end{aosasect2}

%% \begin{aosasect2}{Designs}
\begin{aosasect2}{デザイン}

%% In Thousand Parsec, both weapons and ships may be composed of various
%% components. These components are combined to form the basis of a
%% Design---a prototype for something which can be built and used within
%% the game. When creating a ruleset, the designer has to make an almost
%% immediate decision: should the ruleset allow dynamic creation of
%% weapon and ship designs, or simply use a predetermined list of
%% designs? On the one hand, a game using pre-packaged designs will be
%% easier to develop and balance, but on the other hand, dynamic creation
%% of designs adds an entirely new level of complexity, challenge, and
%% fun to the game.
Thousand Parsecでは、兵器や船はさまざまなコンポーネントで構成されている。
こういったコンポーネントを組み合わせたものが、デザインの基盤となる。
デザインとは、ゲームの中で組み立てたり使ったりする何かのプロトタイプのことだ。
ルールセットを作ろうとすると、デザイナーはこんな決断を迫られる。
そのルールセットで兵器や船のデザインを動的に作れるようにする？
それとも、あらかじめ用意したデザインしか使えないようにする？
用意されたデザインしか使えないようにしてしまえばルールセットを作るのも簡単になるし
バランスも保ちやすい。一方、動的にデザインを作れるようにすれば、
ルールセットを作るのは複雑で難しくなるが、そのぶんゲームは楽しくなる。

%% User-created designs allow a game to become far more advanced. Since
%% users must strategically design their own ships and their armaments, a
%% stratum of variance is added to the game which can help to mitigate
%% otherwise great advantages that might be conferred on a player based
%% on luck (e.g., of placement) and other aspects of game strategy. These
%% designs are governed by the rules of each component, outlined in the
%% Thousand Parsec Component Language (TPCL, covered later in this
%% chapter), and specific to each ruleset. The upshot is that no
%% additional programming of functionality is necessary on the part of
%% the developer to implement the design of weapons and ships;
%% configuring some simple rules for each component available in the
%% ruleset is sufficient.
ユーザーがデザインを作れるようにすると、ゲームはより高度なものになる。
ユーザーは自分の船やその武装を戦略的に設計しないといけないので、ゲームにいっそうの変化が加わることになる。
プレイヤーが配置された場所がたまたまよい場所だったとか、その他のゲーム戦略上得られた利点などを
打ち消す助けになるだろう。
これらのデザインは各コンポーネントのルールの影響を受ける。コンポーネントのルールは後述する
Thousand Parsec Component Language (TPCL)
で記述されており、各ルールセットに固有のものである。
要するに、兵器や船のデザインを実装するときに、新たに機能をプログラミングする必要がないということだ。
ルールセットで定義されているコンポーネント用にシンプルなルールを設定するだけでよいことになる。

%% Without careful planning and proper balance, the great advantage of
%% using custom designs can become its downfall. In the later stages of a
%% game, an inordinate amount of time can be spent designing new types of
%% weapons and ships to build. The creation of a good user experience on
%% the client side for design manipulation is also a challenge. Since
%% design manipulation can be an integral part of one game, while
%% completely irrelevant to another, the integration of a design window
%% into clients is a significant obstacle. Thousand Parsec's most
%% complete client, tpclient-pywx, currently houses the launcher for this
%% window in a relatively out-of-the-way place, in a sub-menu of the menu
%% bar (which is rarely used in-game otherwise).
念入りに計画してきちんとバランスを取らないと、
カスタムデザインを使う利点も台無しになってしまう。
ゲームが後半に進むと、多くの時間を割いて
新型の兵器や船のデザインをすることになる。
クライアント側でのデザインの操作をうまくできるようにするもまた大変な作業だ。
デザインの操作はゲームの中でも重要な位置を占めるが、その他の部分とはあまり関係がない。
デザインウィンドウをクライアントに統合してしまうと相当邪魔になってしまう。
Thousand Parsecで最も完成度の高いクライアントであるtpclient-pywx
の場合は、デザインウィンドウのランチャーを比較的目立たない場所に用意している。
メニューバーのサブメニューの中で、ゲーム中にはめったに使わないところだ。

%% The Design functionality is designed to be easily accessible to
%% ruleset developers, while allowing games to expand to virtually
%% unlimited levels of complexity.  Many of the existing rulesets allow
%% for only predetermined designs. \emph{Missile and Torpedo Wars},
%% however, allows for full weapon and ship design from a variety of
%% components.
デザイン機能は、ルールセットの開発者が簡単に使えるように作られている。
これを使えば、ゲームを拡張して事実上無制限に複雑化できる。
既存のルールセットの多くは、事前に用意されたデザインしか使えないようになっているが、
\emph{Missile and Torpedo Wars}は兵器や船をさまざまなコンポーネントでデザインできるようになっている。

\end{aosasect2}

\end{aosasect1}

%% \begin{aosasect1}{The Thousand Parsec Protocol}
\begin{aosasect1}{Thousand Parsecプロトコル}

%% One might say that the Thousand Parsec protocol is the basis upon
%% which everything else in the project is built. It defines the features
%% available to ruleset writers, how servers should work, and what
%% clients should be able to handle. Most importantly, like an
%% interstellar communications standard, it allows the various software
%% components to understand one another.
Thousand Parsecプロトコルは、プロジェクトを組み立てるのに必要なあらゆるものの
基盤であるという人もいる。このプロトコルでは、
ルールセットの作者が使える機能やサーバー側の動き、
そしてクライアント側でなにを処理できるのかなどを定義する。
最も大切なのは、惑星間通信の標準規格のように、
各種ソフトウェアコンポーネントがお互いに理解し合えるようにすることだ。

%% The server manages the actual state and dynamics of a game according
%% to the instructions provided by the ruleset. Each turn, a player's
%% client receives some of the information about the state of the game:
%% objects and their ownership and current state, orders in progress,
%% resource stockpiles, technological progress, messages, and everything
%% else visible to that particular player. The player can then perform
%% certain actions given the current state, such as issuing orders or
%% creating designs, and send these back to the server to be processed
%% into the computation of the next turn. All of this communication is
%% framed in the Thousand Parsec protocol. An interesting and quite
%% deliberate effect of this architecture is that AI clients---which are
%% external to the server/ruleset and are the only means of providing
%% computer players in a game---are bound by the same rules as the
%% clients human players use, and thus cannot ``cheat'' by having unfair
%% access to information or by being able to bend the rules.
サーバーでは、ゲームの動的な状態をルールセットの指示に従って管理する。
ターンごとに、プレイヤーのクライアントはゲームの状態に関する何らかの情報を受け取る。
オブジェクトとその所有者そして現状、進行中の命令、資源の貯蔵量、技術開発の進捗、
メッセージ、その他プレイヤーが見るあらゆるものに関する情報だ。
プレイヤーは、現状で与えられた選択肢の中から何らかのアクションを実行する。
命令を実行したりデザインを作ったりといったものだ。
そのアクションがサーバーに返され、サーバー側では次のターンに向けた計算処理を行う。
これらすべてのやりとりが、Thousand Parsecプロトコルの枠組みの中で行われるのだ。
このアーキテクチャのおかげで、興味深い効果が得られる。AI(人工知能)クライアント
---サーバーやルールセットとは別に、コンピューター側のプレイヤーとしてゲームに参加するだけのクライアント---
も人間のプレイヤーと同様のルールに縛られるので、
人間が見ることのできない情報にこっそりアクセスしたりルールをねじ曲げたりといった
いわゆる「チート」ができなくなるのだ。

%% The protocol specification describes a series of frames, which are
%% hierarchical in the sense that each frame (except the Header frame)
%% has a base frame type to which it adds its own data. There are a
%% variety of abstract frame types which are never explicitly used, but
%% simply exist to describe bases for concrete frames. Frames may also
%% have a specified direction, with the intent that such frames need only
%% be supported for sending by one side (server or client) and receiving
%% by the other.
プロトコルの仕様では、一連のフレームを定義している。
これは階層型になっており、Headerフレームを除く各フレームが基底フレーム型を持っている。
基底フレーム型に対して独自のデータを追加する方式だ。
さまざまな抽象フレーム型も用意されている。これらは明示的に使うものではなく、
単に具象フレームを作るときのベースとして使うためだけのものだ。
フレームには方向の指定も含まれている。これは、ひとつのフレームが、
サーバーあるいはクライアントのどちらか一方からもう一方への送信にだけ対応すればよいというように
するためのものである。

%% The Thousand Parsec protocol is designed to function either standalone
%% over TCP/IP, or tunnelled through another protocol such as HTTP.  It
%% also supports SSL encryption.
Thousand ParsecプロトコルはTCP/IP越しでそれ単体でも機能するし、
HTTPのような別のプロトコル上のトンネル経由でも機能するように作られている。
また、SSLによる暗号化にも対応している。

%% \begin{aosasect2}{Basics}
\begin{aosasect2}{基本}

%% The protocol provides a few generic frames which are ubiquitous in
%% communication between client and server. The previously mentioned
%% \code{Header} frame simply provides a basis for all other frames via
%% its two direct descendants, the \code{Request} and \code{Response}
%% frames. The former is the basis for frames which initiate
%% communication (in either direction), and the latter for frames which
%% are prompted by these. The \code{OK} and \code{Fail} frames (both
%% \code{Response} frames) provide the two values for Boolean logic in
%% the exchange. A \code{Sequence} frame (also a \code{Response})
%% indicates to the recipient that multiple frames are to follow in
%% response to its request.
いくつかの汎用的なフレームをプロトコルで提供している。
これは、クライアントとサーバーとの間の通信で常に利用するものだ。
先述の\code{Header}フレームは、単に他のすべてのフレームの基盤となるためだけのもので、
これを直接継承したフレーム\code{Request}と\code{Response}経由で基盤を提供する。
\code{Request}フレームは(クライアントからサーバー、あるいはサーバーからクライアントへの)通信を開始するときの基盤となり、
\code{Response}フレームはその通信が引き起こすものに対応するフレームとなる。
\code{OK}フレームと\code{Fail}フレーム(どちらも\code{Response})は、
通信の中でのBooleanロジックの二つの値を表す。
\code{Sequence}フレーム(これも\code{Response})は、
リクエストに対するレスポンスが複数のフレームになることを受信者に通知する。

%% Thousand Parsec uses numerical IDs to address things. Accordingly, a
%% vocabulary of frames exists to push around data via these IDs. The
%% \code{Get With ID} frame is the basic request for things with such an
%% ID; there is also a \code{Get With ID and Slot} frame for things which
%% are in a ``slot'' on a parent thing which has an ID (e.g., an order on
%% an object). Of course, it is often necessary to obtain sequences of
%% IDs, such as when initially populating the client's state; this is
%% handled using \code{Get ID Sequence} type requests and \code{ID
%% Sequence} type responses. A common structure for requesting multiple
%% items is a \code{Get ID Sequence} request and \code{ID Sequence}
%% response, followed by a series of \code{Get With ID} requests and
%% appropriate responses describing the item requested.
Thousand Parsecは、何かを表すときに数値のIDを利用する。
そのため、IDを指定してデータのやりとりをするフレームも用意されている。
\code{Get With ID}フレームは、IDを使って作業をするための基本的なリクエストとなる。
それ以外にも\code{Get With ID and Slot}フレームもある。
これは、IDを持つ親の「スロット」内にあるもの(あるオブジェクトに対する命令など)を扱うリクエストだ。
もちろん、IDのシーケンスを取得する必要に迫られることもある。最初にクライアントの状態を設定するときなどである。
こんなときには、\code{Get ID Sequence}型のリクエストと\code{ID Sequence}型のレスポンスを利用する。
複数のアイテムをやりとりするときによく使われるのが\code{Get ID Sequence}リクエストと
\code{ID Sequence}レスポンスで、それに続けて一連の\code{Get With ID}
リクエストを実行して個々のアイテムを表すレスポンスを得る。

\end{aosasect2}

%% \begin{aosasect2}{Players and Games}
\begin{aosasect2}{プレイヤーとゲーム}

%% Before a client can begin interacting with a game, some formalities
%% need to be addressed. The client must first issue a \code{Connect}
%% frame to the server, to which the server might respond with \code{OK}
%% or \code{Fail}---since the \code{Connect} frame includes the client's
%% protocol version, one reason for failure might be a version
%% mismatch. The server can also respond with the \code{Redirect} frame,
%% for moves or server pools. Next, the client must issue a \code{Login}
%% frame, which identifies and possibly authenticates the player; players
%% new to a server can first use the \code{Create Account} frame if the
%% server allows it.
クライアントがゲームに参加するには、いくつかの手続きが必要だ。
まず最初に、サーバーに\code{Connect}フレームを発行しなければいけない。
これに対してサーバーは\code{OK}あるいは\code{Fail}で応答する。
\code{Fail}になるのは、たとえば\code{Connect}フレームに含まれるクライアント側のプロトコルのバージョンが
サーバー側と一致しない場合などである。サーバー側では\code{Redirect}
フレームを返すこともできる。他のサーバーに移動させたりサーバープールを使ったりする場合だ。
次にクライアントが発行する必要があるのが\code{Login}フレームだ。
ここでプレイヤーの認証情報を指定する。はじめてそのサーバーに接続するプレイヤーの場合は、
サーバー側でアカウントの作成を許している場合はまず\code{Create Account}フレームを使える。

%% Because of the vast variability of Thousand Parsec, the client needs
%% some way to ascertain which protocol features are supported by the
%% server; this is accomplished via the \code{Get Features} request and
%% \code{Features} response. Some of the features the server might
%% respond with include:
Thousand Parsecは常に変化し続けるので、プロトコルにある機能がサーバー側でサポートされているかどうかを
何らかの手段で確かめる必要がある。そのために使うのが\code{Get Features}リクエストと
\code{Features}レスポンスだ。サーバー側が返すレスポンスには次のような情報が含まれる。

\begin{aosaitemize}

  %% \item Availability of SSL and HTTP tunnelling (on this port or another
  %% port).
  \item SSLおよびHTTPのトンネリングが(このポートあるいは別のポートで)使えるかどうか。

  %% \item Support for server-side component property calculation.
  \item サーバー側でのコンポーネントのプロパティの算出をサポートしているか。

  %% \item Ordering of ID sequences in responses (ascending vs.\ descending).
  \item レスポンスにおけるIDシーケンスの並び順(昇順あるいは降順)。

\end{aosaitemize}

%% Similarly, the \code{Get Games} request and sequence of \code{Game}
%% responses informs the client about the nature of the active games on
%% the server. A single \code{Game} frame contains the following
%% information about a game:
同様に、\code{Get Games}リクエストとそれに対応する一連の\code{Game}レスポンスが、
クライアントに対してそのサーバー上でアクティブなゲームの特性を示す。
一つの\code{Game}フレームには、あるゲームに対する次のような情報が含まれる。

\begin{aosaitemize}

  %% \item The long (descriptive) name of the game.
  \item そのゲームの長い(説明的な)名前。

  %% \item A list of supported protocol versions.
  \item サポートするプロトコルのバージョンの一覧。

  %% \item The type and version of the server.
  \item サーバーの型とバージョン。

  %% \item The name and version of the ruleset.
  \item ルールセットの名前とバージョン。

  %% \item A list of possible network connection configurations.
  \item 利用可能なネットワーク接続設定の一覧。

  %% \item A few optional items (number of players, number of objects,
  %% administrator details, comment, current turn number, etc.).
  \item オプションの項目(プレイヤー数やオブジェクト数、管理者の詳細情報、コメント、現在のターン番号など)。

  %% \item The base URL for media used by the game.
  \item ベームが使うメディア用のベースURL。

\end{aosaitemize}

%% It is, of course, important for a player to know who he or she is up
%% against (or working with, as the case may be), and there is a set of
%% frames for that. The exchange follows the common item sequence pattern
%% with a \code{Get Player IDs} request, a \code{List of Player IDs}
%% response, and a series of \code{Get Player Data} requests and
%% \code{Player Data} responses. The \code{Player Data} frame contains
%% the player's name and race.
もちろん、プレイヤーにとっても、自分の対戦相手(あるいは仲間)の情報を知ることが重要だ。
そのためのフレームも用意されている。一般的な項目パターンの交換をするには、
まず\code{Get Player IDs}リクエストに対して\code{List of Player IDs}レスポンスを得て、
それから各プレイヤーについての\code{Get Player Data}リクエストと\code{Player Data}レスポンスを利用する。
\code{Player Data}フレームには、プレイヤーの名前と種族が含まれている。

%% Turns in the game are also controlled via the protocol. When a player
%% has finished performing actions, he or she may signal readiness for
%% the next turn via the \code{Finished Turn} request; the next turn is
%% computed when all players have done so. Turns also have a time limit
%% imposed by the server, so that slow or unresponsive players cannot
%% hold up a game; the client normally issues a \code{Get Time Remaining}
%% request, and tracks the turn with a local timer set to the value in
%% the server's \code{Time Remaining} response.
ゲームでのターンもこのプロトコルによって制御される。
プレイヤーが何らかのアクションを終えると、次のターンの準備が整ったことを表す
\code{Finished Turn}リクエストを送る。全プレイヤーがこのリクエストを送り終えた時点で
次のターンに向けた計算が始まる。ターンには、サーバーで定めた時間制限もある。
そのため、反応が遅れたり応答がなかったりしたプレイヤーはゲームについて行けなくなる。
クライアントは一般に、\code{Get Time Remaining}リクエストを発行して、
ローカルのタイマーの値をサーバーの\code{Time Remaining}レスポンスに合わせる。

%% Finally, Thousand Parsec supports messages for a variety of purposes:
%% game broadcasts to all players, game notifications to a single player,
%% player-to-player communications. These are organized into ``board''
%% containers which manage ordering and visibility; following the item
%% sequence pattern, the exchange consists of a \code{Get Board IDs}
%% request, a \code{List of Board IDs} response, and a series of
%% \code{Get Board} requests and \code{Board} responses.
最後に、Thousand Parsecではさまざまな目的で使うためのメッセージに対応している。
ゲームから全プレイヤーへの通知、ゲームから特定のプレイヤーへの通知、
そしてプレイヤーどうしのコミュニケーションなどに使うものだ。
これらは``board''コンテナが取り仕切っており、ここでメッセージの順序や表示を管理している。
項目の並びのパターンに従って、\code{Get Board IDs}リクエストと\code{List of Board IDs}
レスポンス、そして一連の\code{Get Board}リクエストと\code{Board}レスポンスが行われる。

%% Once the client has information on a message board, it can issue
%% \code{Get Message} requests to obtain messages on the board by slot
%% (hence, \code{Get Message} uses the \code{Get With ID and Slot} base
%% frame); the server responds with \code{Message} frames containing the
%% message subject and body, the turn on which the message was generated,
%% and references to any other entities mentioned in the message. In
%% addition to the normal set of items encountered in Thousand Parsec
%% (players, objects, and the like), there are also some special
%% references including message priority, player actions, and order
%% status. Naturally, the client can also add messages using the
%% \code{Post Message} frame---a vehicle for a \code{Messsage}
%% frame---and delete them using the \code{Remove Message} frame (based
%% on the \code{GetMessage} frame).
クライアントがメッセージボードの情報を得たら、\code{Get Message}リクエスト
を使ってボード上のメッセージをスロットで取得できる
(従って、\code{Get Message}は基底フレームとして\code{Get With ID and Slot}を使う)。
サーバーは\code{Message}フレームを返す。この中にはメッセージのタイトルと本文やそのメッセージが作られたターン、
メッセージ内で言及されているエンティティへの参照などが含まれる。
Thousand Parsecで通常現れるアイテム(プレイヤーやオブジェクトなど)
に加えて、特殊な参照が存在する。メッセージの優先度やプレイヤーのアクション、
その他のステータスなどである。もちろん、クライアントは\code{Post Message}
フレーム(\code{Messsage}フレームを運ぶメディア)でメッセージを追加できる。
メッセージを削除するときに使うのは\code{Remove Message}フレーム(基底フレームは\code{GetMessage})
だ。

\end{aosasect2}

%% \begin{aosasect2}{Objects, Orders, and Resources}
\begin{aosasect2}{オブジェクト、命令、そして資源}

%% The bulk of the process of interacting with the universe is
%% accomplished through a series of frames comprising the functionality
%% for objects, orders, and resources.
ゲーム世界でのやりとりの多くは、オブジェクトや命令そして資源に対する
各種機能を含むフレームを使って行う。

%% The physical state of the universe---or at least that part of it that
%% the player controls or has the ability to see---must be obtained upon
%% connecting, and every turn thereafter, by the client. The client
%% generally issues a \code{Get Object IDs} request (a \code{Get ID
%% Sequence}), to which the server replies with a \code{List of Object
%% IDs} response. The client can then request details about individual
%% objects using \code{Get Object by ID} requests, which are answered
%% with \code{Object} frames containing such details---again subject to
%% visibility by the player---as their type, name, size, position,
%% velocity, contained objects, applicable order types, and current
%% orders. The protocol also provides the \code{Get Object IDs by
%% Position} request, which allows the client to find all objects
%% within a specified sphere of space.
クライアントは、接続時そして各ターンの終了時に世界の物理的な状態
---少なくとも、そのプレイヤーから見えて制御できる範囲の状態---を取得する必要がある。
クライアントは一般に、\code{Get Object IDs}リクエスト(\code{Get ID Sequence})
を発行し、サーバーはそれに対して\code{List of Object IDs}で応える。
クライアントが個々のオブジェクトの詳細を知るには\code{Get Object by ID}リクエストを使う。
その応答は\code{Object}フレームになり、そのプレイヤーから見える範囲の詳細が含まれている。
その型や名前、サイズ、位置、速度、内包するオブジェクト、使える命令、現在の命令などである。
プロトコルでは\code{Get Object IDs by Position}リクエストも用意している。
これを使うと、指定した球体の内部にある全オブジェクトを探すことができる。

%% The client obtains the set of possible orders following the usual item
%% sequence pattern by issuing a \code{Get Order Description IDs} request
%% and, for each ID in the \code{List of Order Description IDs} response,
%% issuing a \code{Get Order Description} request and receiving a
%% \code{Order Description} response. The implementation of the orders
%% and order queues themselves has evolved markedly over the history of
%% the protocol. Originally, each object had a single order queue. The
%% client would issue an \code{Order} request (containing the order type,
%% target object, and other information), receive an \code{Outcome}
%% response detailing the expected result of the order, and, after
%% completion of the order, receive a \code{Result} frame containing the
%% actual result.
クライアントが使える命令を取得するには、通常のアイテム群のときと同様のパターンを使う。
つまり、まず\code{Get Order Description IDs}リクエストを発行し、
返ってきたレスポンス\code{List of Order Description IDs}の中の各IDに対して
\code{Get Order Description}リクエストをして\code{Order Description}を受け取る。
命令群と命令キューの実装は、このプロトコルの歴史とともにめざましく成長してきた。
最初の頃は、各オブジェクトがひとつの命令キューを持っていたのだ。
クライアントが\code{Order}リクエスト(命令の型や対象オブジェクトなどの情報を含む)
を発行して\code{Outcome}レスポンス(命令の結果として期待される詳細)を受け取り、
命令が完了したら実際の結果を\code{Result}フレームで受け取っていた。

%% In the second version, the \code{Order} frame incorporated the
%% contents of the \code{Outcome} frame (since, based on the order
%% description, this did not require the server's input), and the
%% \code{Result} frame was removed entirely. The latest version of the
%% protocol refactored the order queue out of objects, and added the
%% \code{Get Order Queue IDs}, \code{List of Order Queue IDs}, \code{Get
%% Order Queue}, and \code{Order Queue} frames, which work similarly to
%% the message and board functionality\footnote{Actually, it's the other
%% way around: messages and boards were derived from orders in the
%% second version of the protocol.}.  The \code{Get Order} and
%% \code{Remove Order} frames (both \code{GetWithIDSlot} requests) allow
%% the client to access and remove orders on a queue, respectively. The
%% \code{Insert Order} frame now acts as a vehicle for the \code{Order}
%% payload; this was done to allow for another frame, \code{Probe Order},
%% which is used by the client in some cases to obtain information for
%% local use.
次のバージョンでは\code{Order}フレームが\code{Outcome}フレームの内容を取り込み
(というのも、命令の内容によってはサーバーの入力を必要としないからだ)、
\code{Result}フレームは完全に廃止された。
最新版のプロトコルでは命令キューをオブジェクトから切り離し、
\code{Get Order Queue IDs}や\code{List of Order Queue IDs}、\code{Get Order Queue}
そして\code{Order Queue}といったフレームを追加した。これらはメッセージやボード機能と同じように動く
\footnote{実際のところ、別の見方もできる。メッセージやボードが、第二バージョンのプロトコルから派生したものだという見方だ。}。
\code{Get Order}フレームおよび\code{Remove Order}フレーム(どちらも\code{GetWithIDSlot}リクエスト)
を使えば、クライアントがキューにある命令を取得したり削除したりできる。
\code{Insert Order}フレームは、\code{Order}を運ぶための道具だ。
これを用意したのは、別のフレーム\code{Probe Order}を考慮したためだ。
このフレームを使って、クライアントがローカルで使うための情報を取得することになる。

%% Resource descriptions also follow the item sequence pattern: a
%% \code{Get Resource Description IDs} request, a \code{List of Resource
%% Description IDs} response, and a series of \code{Get Resource
%% Description} requests and \code{Resource Description} responses.
資源についての説明を取得するのも、通常のアイテム群のパターンと同じだ。
まず\code{Get Resource Description IDs}リクエストを発行して\code{List of Resource Description IDs}
レスポンスが取得し、一連の\code{Get Resource Description}リクエストで
\code{Resource Description}レスポンスを得ることになる。

\end{aosasect2}

%% \begin{aosasect2}{Design Manipulation}
\begin{aosasect2}{デザインの操作}

%% The handling of designs in the Thousand Parsec Protocol is broken down
%% into the manipulation of four separate sub-categories: categories,
%% components, properties, and designs.
Thousand Parsecプロトコルにおけるデザインの操作は、
四つのサブカテゴリの操作に切り分けられる。
カテゴリ、コンポーネント、プロパティ、そしてデザインだ。

%% Categories differentiate the different design types. Two of the most
%% commonly used design types are ships and weapons. Creating a category
%% is simple, as it consists only of a name and description; the
%% \code{Category} frame itself contains only these two strings. Each
%% category is added by the ruleset to the Design Store using an
%% \code{Add Category} request, a vehicle for the \code{Category}
%% frame. The remainder of the management of categories is handled in the
%% usual item sequence pattern with the \code{Get Category IDs} request
%% and \code{List of Category IDs} response.
カテゴリは、さまざまなデザイン型を区別するためのものだ。
最も一般的に使われているデザイン型は、船と兵器の二つである。
カテゴリを作るのは単純なことで、名前と説明を指定するだけでよい。
\code{Category}フレーム自体に含まれるのは、この二つの文字列だけである。
ルールセットがカテゴリをデザインストアに追加するときに使うのが\code{Add Category}
リクエストで、このリクエストが\code{Category}フレームを運ぶ。
カテゴリ管理のその他の作業を受け持つのは通常のアイテム群のパターンで、
\code{Get Category IDs}リクエストと\code{List of Category IDs}レスポンスを使う。

%% Components consist of the different parts and modules which comprise a
%% design. This can be anything from the hull of a ship or missile to the
%% tube that a missile is housed in. Components are a bit more involved
%% than categories. A \code{Component} frame contains the following
%% information:
コンポーネントには、そのデザインを構成するさまざまなパーツやモジュールが含まれている。
船体からミサイル、そしてミサイルを据え付ける砲台まであらゆるものが考えられる。
コンポーネントは、カテゴリに比べて少し込み入っている。
\code{Component}フレームに含まれる情報は次のとおりだ。

\begin{aosaitemize}

  %% \item The name and description of the component.
  \item コンポーネントの名前と説明。

  %% \item A list of categories to which the component belongs.
  \item コンポーネントが属するカテゴリのリスト。

  %% \item A \code{Requirements} function, in Thousand Parsec Component
  %% Language (TPCL).
  \item \code{Requirements}関数。Thousand Parsec Component Language (TPCL)形式。

  %% \item A list of properties and their corresponding values.
  \item プロパティとその値のリスト。

\end{aosaitemize}

%% Of particular note is the \code{Requirements} function associated with
%% the component. Since components are the parts that make up a ship,
%% weapon, or other constructed object, it is necessary to ensure that
%% they are valid when adding them to a design. The \code{Requirements}
%% function verifies that each component added to the design conforms to
%% the rules of other previously added components. For example, in
%% \code{Missile and Torpedo Wars}, it is impossible to hold an Alpha
%% Missile in a ship without an Alpha Missile Tube. This verification
%% occurs on both the client side and the server side, which is why the
%% entire function must appear in a protocol frame, and why a concise
%% language (TPCL, covered later in the chapter) was chosen for it.
コンポーネントに関連づけられた\code{Requirements}関数について、もう少し詳しく説明する。
コンポーネントを組み合わせて船や兵器などのオブジェクトを作ることになるので、
デザインに追加するときにその妥当性を保証できなければいけない。
\code{Requirements}関数は、デザインに追加する各コンポーネントが
すでに追加済みの他のコンポーネントのルールを満たすかどうかを検証する。
たとえば\code{Missile and Torpedo Wars}では、船にAlpha Missileを搭載するには
Alpha Missile Tubeが必須となる。こういった検証が、クライアント側とサーバー側の
両方で行われる。そのためには関数全体がプロトコルのフレームに存在しなければいけないし、
簡潔な言語(後述するTPCL)を採用したのもそのためだ。

%% All of a design's properties are communicated via \code{Property}
%% frames. Each ruleset exposes a set of properties used within the
%% game. These typically include things like the number of missile tubes
%% of a certain type allowed on a ship, or the amount of armor included
%% with a certain hull type. Like \code{Component} frames,
%% \code{Property} frames make use of TPCL\@. A \code{Property} frame
%% contains the following information:
デザインのプロパティに関する通信は、すべて\code{Property}フレームを使って行う。
各ルールセットは、ゲーム内で使えるプロパティ群を公開している。
一般的なプロパティとしては、一隻の船に搭載できる砲台の最大数や
船体の装甲などがある。\code{Component}フレームと同様に、\code{Property}
フレームでもTPCLを使っている。\code{Property}フレームに含まれる情報は次のとおりだ。

\begin{aosaitemize}

  %% \item The (display) name and description of the property.
  \item プロパティの(表示用の)名前とその説明。

  %% \item A list of categories to which the property belongs.
  \item プロパティが属するカテゴリのリスト。

  %% \item The name (valid TPCL identifier) of the property.
  \item プロパティの(TPCLの識別しとして使える形式の)名前。

  %% \item The rank of the property.
  \item プロパティのランク。

  %% \item \code{Calculate} and \code{Requirements} functions, in Thousand Parsec Component Language (TPCL).
  \item \code{Calculate}関数および\code{Requirements}関数。Thousand Parsec Component Language (TPCL)形式。

\end{aosaitemize}

%% The rank of a property is used to distinguish a hierarchy of
%% dependencies. In TPCL, a function may not depend on any property which
%% has a rank less than or equal to this property. This means that if one
%% had an Armor property of rank 1 and an Invisibility property of rank
%% 0, then the Invisibility property could not directly depend on the
%% Armor property. This ranking was implemented as a method of curtailing
%% circular dependencies. The \code{Calculate} function is used to define
%% how a property is displayed, differentiating the methods of
%% measurement. \code{Missile and Torpedo Wars} uses XML to import game
%% properties from a game data file. \aosafigref{fig.tp.prop} shows an
%% example property from that game data.
プロパティのランクは、依存関係の階層を識別するために利用する。
TPCLでは、ある関数がこのプロパティのランク以下のプロパティには依存していないことがある。
つまり、何かがランク1のArmorプロパティとランク0のInvisibilityプロパティを持っていた場合、
Invisibilityプロパティは直接Armorプロパティに依存することができない。
ランクを導入したのは、循環依存の問題を回避するためだった。
\code{Calculate}関数を使ってそのプロパティの表示方法を定義し、
測定方法を差別化する。
\code{Missile and Torpedo Wars}は、ゲームのデータファイルからXML形式で
プロパティをインポートする。ゲームデータにあるプロパティの例を\aosafigref{fig.tp.prop}
に示す。

\begin{figure}
\begin{verbatim}
<prop>
<CategoryIDName>Ships</CategoryIDName>
<rank value="0"/>
<name>Colonise</name>
<displayName>Can Colonise Planets</displayName>
<description>Can the ship colonise planets</description>
<tpclDisplayFunction>
    (lambda (design bits) (let ((n (apply + bits))) (cons n (if (= n 1) "Yes" "No")) ) )
</tpclDisplayFunction>
<tpclRequirementsFunction>
    (lambda (design) (cons #t ""))
</tpclRequirementsFunction>
</prop>
\end{verbatim}
%% \caption{Example Property}
\caption{プロパティの例}
\label{fig.tp.prop}
\end{figure}

%% In this example, we have a property belonging to the Ships category,
%% of rank~0. This property is called Colonise, and relates to the
%% ability of a ship to colonize planets. A quick look at the TPCL
%% \code{Calculate} function (listed here as \code{tpclDisplayFunction})
%% reveals that this property outputs either ``Yes'' or ``No'' depending
%% on whether the ship in question has said capability. Adding properties
%% in this fashion gives the ruleset designer granular control over
%% metrics of the game and the ability to easily compare them and output
%% them in a player-friendly format.
この例では、Shipsカテゴリに属するランク0のプロパティを扱っている。
プロパティの名前はColoniseで、その船が惑星を占領できるかどうかに関わるものだ。
TPCLの\code{Calculate}関数(\code{tpclDisplayFunction})をざっと眺めてみるとわかるとおり、
このプロパティの出力は``Yes''か``No''のいずれかで、船がその機能を持っているかどうかを表す。
このようにプロパティを追加していくことで、ルールセットを作る人がゲームをよりきめ細やかに作り込めるようになり、
ユーザーにわかりやすい形式でそのプロパティを表示できるようにもなる。

%% The actual design of ships, weapons, and other game artifacts are
%% created and manipulated using the \code{Design} frame and related
%% frames. In all current rulesets, these are used for building ships and
%% weaponry using the existing pool of components and properties. Since
%% the rules for designs are already handled in TPCL \code{Requirements}
%% functions in both properties and components, the creation of a design
%% is a bit simpler. A \code{Design} frame contains the following
%% information:
船や兵器などの実際のデザインを作ったり操作したりするときに使うのが、
\code{Design}フレームとそれに関連するフレーム群だ。
いま出回っているすべてのルールセットは、これらを使って
既存のコンポーネントプールおよびプロパティプールから船や兵器を組み立てている。
プロパティやコンポーネントに関するデザイン時のルールは
TPCLの\code{Requirements}関数で処理されているので、デザインを作ることは少しシンプルになる。
\code{Design}フレームの内容は次のとおりだ。

\begin{aosaitemize}

  %% \item The name and description of the design.
  \item デザインの名前とその説明。

  %% \item A list of categories to which the design belongs.
  \item デザインが属するカテゴリのリスト。

  %% \item A count of the number of instances of the design.
  \item デザインのインスタンス数のカウンタ。

  %% \item The owner of the design.
  \item デザインの所有者。

  %% \item A list of component IDs and their corresponding counts.
  \item コンポーネントIDとそれに対応するカウントのリスト。

  %% \item A list of properties and their corresponding display string.
  \item プロパティとそれに対応する表示用文字列のリスト。

  %% \item The feedback on the design.
  \item デザインへのフィードバック。

\end{aosaitemize}

%% This frame is a bit different from the others. Most notably, since a
%% design is an owned item in the game, there is a relation to the owner
%% of each design. A design also tracks the number of its instantiations
%% with a counter.
このフレームはその他のフレームとは少し違う。
最も注目すべきなのは、デザインというのはゲーム内で誰かが所有するアイテムだという点だ。
つまり、個々のデザインには所有者がいることになる。
また、個々のデザインは自分自身のインスタンスが作られた回数を覚えている。

\end{aosasect2}

%% \begin{aosasect2}{Server Administration}
\begin{aosasect2}{サーバー管理}

%% A server administration protocol extension is also available, allowing
%% for remote live control of supporting servers. The standard use case
%% is to connect to the server via an administration client---perhaps a
%% shell-like command interface or a GUI configuration panel---to change
%% settings or perform other maintenance tasks. However, other, more
%% specialized uses are possible, such as behind-the-scenes management
%% for single-player games.
サーバー管理プロトコルの拡張も用意されており、
それに対応したサーバーをリモート制御できるようになっている。
一般的な使い道は、管理クライアント(シェル風のコマンドラインインターフェイスだったり、
あるいはGUIの設定パネルだったりするだろう)経由でサーバーに接続して
設定の変更やその他の保守作業をこなすことだ。
しかし、それ以外の使い方もできる。シングルプレイヤーのゲームで裏方の処理を管理することなどだ。

%% As with the game protocol described in the preceding sections, the
%% administration client first negotiates a connection (on a port
%% separate from the normal game port) and authenticates using
%% \code{Connect} and \code{Login} requests. Once connected, the client
%% can receive log messages from and issue commands to the server.
先のセクションで説明したゲームのプロトコルと同様、管理クライアントもまずは
接続のネゴシエーション(ゲームで使っているポートとは別のポートを利用する)
を行ってから認証に進む。利用するのは\code{Connect}リクエストと\code{Login}リクエストだ。
接続を確立したら、サーバーからログメッセージを受け取ったりサーバーにコマンドを発行したりできるようになる。

%% Log messages are pushed to the client via \code{Log Message}
%% frames. These contain a severity level and text; as appropriate to the
%% context, the client can choose to display all, some, or none of the
%% log messages it receives.
ログメッセージをクライアントに送るときに使うのが\code{Log Message}フレームだ。
この中には、深刻度とメッセージ本文が含まれている。コンテキストに合わせて、
クライアント側ではそれを全部表示してもいいし一部だけを表示することもある。
あるいは一切メッセージを無視することもある。

%% The server may also issue a \code{Command Update} frame instructing
%% the client to populate or update its local command set; supported
%% commands are exposed to the client in the server's response to a
%% \code{Get Command Description IDs} frame. Individual command
%% descriptions must then be obtained by issuing a \code{Get Command
%% Description} frame for each, to which the server responds with a
%% \code{Command Description} frame.
サーバーは、\code{Command Update}フレームを発行してクライアント側の
ローカルコマンドセットを更新することもある。サーバー側でサポートするコマンドは、
クライアントからの\code{Get Command Description IDs}フレームへのレスポンスとして公開する。
個々のコマンドの詳細を取得するには、\code{Get Command Description}フレームを発行しなければいけない。
サーバーはそれに対して\code{Command Description}フレームで応答する。

%% This exchange is functionally quite similar to (and, in fact, was
%% originally based on) that of the order frames used in the main game
%% protocol. It allows commands to be described to the user and vetted
%% locally to some degree, minimizing network usage. The administration
%% protocol was conceived at a time when the game protocol was already
%% mature; rather than starting from scratch, the developers found
%% existing functionality in the game protocol which did almost what was
%% needed, and added the code to the same protocol libraries.
このやりとりは、ゲーム本体で使われていた命令関連のフレーム群とよく似ている
(実際、それをもとにして作ったものだ)。これらを使えばコマンドをユーザー側で吟味でき、
ネットワークの流量を抑えられる。管理プロトコルができたのは、
ゲームプロトコルが既に成熟しきった頃だった。そのため、
必要な機能の大半は既にゲームプロトコルにそろっており、
ちょっとしたプロトコルライブラリのコードを追加するだけでよかった。

\end{aosasect2}

\end{aosasect1}

%% \begin{aosasect1}{Supporting Functionality}
\begin{aosasect1}{サポート機能}

%% \begin{aosasect2}{Server Persistence}
\begin{aosasect2}{サーバーの永続化}

%% Thousand Parsec games, like many in the turn-based strategy genre,
%% have the potential to last for quite some time. Besides often running
%% far longer than the circadian rhythms of the players' species, during
%% this extended period the server process might be prematurely
%% terminated for any number of reasons. To allow players to pick up a
%% game where they left off, Thousand Parsec servers provide persistence
%% by storing the entire state of the universe (or even multiple
%% universes) in a database. This functionality is also used in a related
%% way for saving single-player games, which will be covered in more
%% detail later in this section.
Thousand Parsecのゲームは、ターン制の戦略型ゲームの多くがそうであるように、
それなりに時間をかけてプレイする可能性がある。プレイヤーの日々の生活周期を越えて
長時間実行されることもあるので、その間さまざまな理由でサーバープロセスが終了してしまうこともあるだろう。
切断されてしまった時点からゲームを再開できるようにするため、
Thousand Parsecサーバーは永続化機能を提供している。
ゲーム世界全体の状態をデータベースに格納しているのだ。
この機能はシングルプレイヤーゲームを保存する仕組みとしても使われており、
それについては後で詳しく説明する。

%% The flagship server, \code{tpserver-cpp}, provides an abstract
%% persistence interface and a modular plugin system to allow for various
%% database back ends. At the time of writing, \code{tpserver-cpp} ships
%% with modules for MySQL and SQLite.
最先端のサーバーである\code{tpserver-cpp}では抽象化永続インターフェイスが提供されており、
さまざまなデータベースをバックエンドとして使うためのプラグインを作れるシステムもある。
本章の執筆時点で\code{tpserver-cpp}に同梱されているのはMySQL用とSQLite用のプラグインモジュールだ。

%% The abstract \code{Persistence} class describes the functionality
%% allowing the server to save, update, and retrieve the various elements
%% of a game (as described in the Anatomy of a Star Empire section). The
%% database is updated continuously from various places in the server
%% code where the game state changes, and no matter the point at which
%% the server is terminated or crashes, all information to that point
%% should be recovered when the server starts again from the saved data.
抽象クラス\code{Persistence}で、サーバーがゲームのさまざまな要素(『スターエンパイアの世界』で説明したもの)
を扱うための仕組みを提供している。保存したり更新したり、現状を取得したりといった機能だ。
データベースは、ゲームの状態が変わるたびにサーバーのコードのさまざまな場所から継続的に更新される。
どの段階でサーバーが止まったりクラッシュしたりしても、サーバーを再開させれば
その時点でのすべての情報を復旧できなければいけない。

\end{aosasect2}

%% \begin{aosasect2}{Thousand Parsec Component Language}
\begin{aosasect2}{Thousand Parsec Component Language}

%% The Thousand Parsec Component Language (TPCL) exists to allow clients
%% to create designs locally without server interaction---allowing for
%% instant feedback about the properties, makeup, and validity of the
%% designs. This allows the player to interactively create, for example,
%% new classes of starship, by customizing structure, propulsion,
%% instrumentation, defenses, armaments, and more according to available
%% technology.
Thousand Parsec Component Language (TPCL)は、
サーバーとのやりとりなしでクライアントがデザインを作成できるように用意された。
プロパティや見た目、デザインの妥当性などに関するフィードバックをその場で得られるようにしたのだ。
プレイヤーは、たとえば新たなクラスの宇宙船を作ったり
その構造や推力、機材、防御、武装などをカスタマイズできたりする。

%% TPCL is a subset of Scheme, with a few minor changes, though close
%% enough to the Scheme R5RS standard that any compatible interpreter can
%% be used. Scheme was originally chosen because of its simplicity, a
%% host of precedents for using it as an embedded language, the
%% availability of interpreters implemented in many other languages, and,
%% most importantly to an open source project, vast documentation both on
%% using it and on developing interpreters for it.
TPCLはSchemeのサブセットである。多少手を加えてはいるものの
Scheme R5RS規格にほぼ沿っており、R5RS互換のインタプリタならなんでも使える。
Schemeを採用した理由はいくつかある。シンプルであること。
組み込み言語としての採用事例があったこと、
さまざまな他の言語でインタプリタが実装されていること、
そして何よりも重要なのがオープンソースプロジェクトであったことだ。
言語の使い方に関してもインタプリタの開発法に関しても大量のドキュメントがあった。

%% Consider the following example of a \code{Requirements} function in
%% TPCL, used by components and properties, which would be included with
%% a ruleset on the server side and communicated to the client over the
%% game protocol:
次の例はTPCLの\code{Requirements}関数で、コンポーネントやプロパティで使われているものだ。
これをサーバー側のルールセットに組み込み、ゲームのプロトコルを使ってクライアントと通信する。

\begin{verbatim}
(lambda (design)
  (if (> (designType.MaxSize design) (designType.Size design))
      (if (= (designType.num-hulls design) 1)
          (cons #t "")
          (cons #f "Ship can only have one hull")
      )
      (cons #f "This many components can't fit into this Hull")
  )
)
\end{verbatim}

%% Readers familiar with Scheme will no doubt find this code easy to
%% understand. The game (both client and server) uses it to check other
%% component properties (\code{MaxSize}, \code{Size}, and
%% \code{Num-Hulls}) to verify that this component can be added to a
%% design. It first verifies that the \code{Size} of the component is
%% within the maximum size of the design, then ensures that there are no
%% other hulls in the design (the latter test tips us off that this is
%% the \code{Requirements} function from a ship hull).
Schemeになじみのある人なら、ぱっと見ればすぐに理解できるはずだ。
ゲームのクライアントとサーバーは、これを使って他のコンポーネントのプロパティ
(\code{MaxSize}や\code{Size}、そして\code{Num-Hulls})
をチェックし、このコンポーネントをデザインに追加できるかどうかを調べる。
まず最初に、コンポーネントの\code{Size}がデザインの最大サイズにおさまるかどうかを調べ、
次にそのデザインに既に他の船体が存在しないことを確かめる
(後者のテストを見れば、この\code{Requirements}関数が船体のものであることがわかる)。

\end{aosasect2}

%% \begin{aosasect2}{BattleXML}
\begin{aosasect2}{BattleXML}

%% In war, every battle counts, from the short skirmish in deep space
%% between squadrons of small lightly-armed scout craft, to the massive
%% final clash of two flagship fleets in the sky above a capital
%% world. On the Thousand Parsec framework, the details of combat are
%% handled within the ruleset, and there is no explicit client-side
%% functionality regarding combat details---typically, the player will be
%% informed of the initiation and results of combat via messages, and the
%% appropriate changes to the objects will take place (e.g., removal of
%% destroyed ships). Though the player's focus will normally be on a
%% higher level, under rulesets with complex combat mechanics, it may
%% prove advantageous (or, at least, entertaining) to examine the battle
%% in more detail.
戦争では、あらゆる戦いが大切になる。
深宇宙での軽武装な偵察機同士の小競り合いであろうが
首都上空での主力艦隊同士の最終決戦であろうが、それは変わらない。
Thousand Parsecフレームワークでは、戦闘の詳細をルールセットで扱う。
戦闘の詳細に関してクライアント側から明示的に何かできる機能は存在しない。
通常、プレイヤーに知らされるのは、戦闘が始まったこととその結果を表すメッセージだけであり、
それにまつわるオブジェクトへの変更(破壊された船の削除など)もそこで行われる。
プレイヤーが注力するのはもっと上位レベルのことになるが、
ルールセットの内部では複雑な戦闘の仕組みが動いており、
その戦いの内容を詳しく吟味するのも有益(少なくとも興味は持ってもらえる)だろう。

%% This is where BattleXML comes in. Battle data is split into two major
%% parts: the media definition, which provides details about the graphics
%% to be used, and the battle definition, which specifies what actually
%% occurred during a battle. These are intended to be read by a battle
%% viewer, of which Thousand Parsec currently has two: one in 2D and the
%% other in 3D\@. Of course, since the nature of battles are entirely a
%% feature of a ruleset, the ruleset code is responsible for actually
%% producing BattleXML data.
ここで使われているのがBattleXMLだ。
戦闘データは、大きく二つの部分に分かれる。
メディアの定義(利用するグラフィックなどの詳細)
と戦いの定義(戦闘中に実際に発生する出来事)だ。
このデータはバトルビューアが読むことを想定している。現在
Thousand Parsecには二種類のバトルビューアがあり、ひとつは2Dでもうひとつが3Dである。
もちろん、戦いの性質はルールセットで定義するものなので、
実際にBattleXMLのデータを作るのはルールセットのコードの役割となる。

%% The media definition is tied to the nature of the viewer, and is
%% stored in a directory or an archive containing the XML data and any
%% graphics or model files it references. The data itself describes what
%% media should be used for each ship (or other object) type, its
%% animations for actions such as firing and death, and the media and
%% details of its weapons. File locations are assumed to be relative to
%% the XML file itself, and cannot reference parent directories.
メディアの定義はビューアの特性に結びつけられており。
ディレクトリあるいはアーカイブで格納されている。
その内容は、XMLデータおよびそこから参照するグラフィックやモデルのファイルである。
データ自体に記述しているのは、船(あるいはその他のオブジェクト)の型ごとに必要なメディア、
炎上や死亡といったアクションに対応するアニメーション、
そして武器のメディアや詳細である。
ファイルの位置はXMLファイルからの相対パスで参照し、親ディレクトリを参照することはできない。

%% The battle definition is independent of the viewer and media. First,
%% it describes a series of entities on each side at the start of the
%% battle, with unique identifiers and information such as name,
%% description, and type. Then, each round of the battle is described:
%% object movement, weapons fire (with source and target), damage to
%% objects, death of objects, and a log message. How much detail is used
%% to describe each round of battle is dictated by the ruleset.
戦いの定義は、ビューアやメディアからは独立している。
まず、戦闘開始時の両陣営のエンティティについてのIDと情報
(名前や説明、そして型など)を記述する。
次に、戦闘の各ラウンドについて記述する。
オブジェクトの移動や武器の使用(攻撃元と攻撃先)、オブジェクトへのダメージ、
オブジェクトの死亡、ログメッセージなどである。
各ラウンドをどの程度詳細に記述するかはルールセットが決めることだ。

\end{aosasect2}

%% \begin{aosasect2}{Metaserver}
\begin{aosasect2}{メタサーバー}

%% Finding a public Thousand Parsec server to play on 
%% is much like locating a lone stealth scout in deep space---a
%% daunting prospect if one doesn't know where to look. Fortunately,
%% public servers can announce themselves to a metaserver, whose
%% location, as a central hub, should ideally be well-known to players.
公開されているThousand Parsecサーバーを探すというのは、
まるで深宇宙でステルス偵察機を探すようなものだ。
場所を知っていなければ、成功する見込みは薄い。
幸いにも、公開サーバーはメタサーバーにアナウンスできるようになっている。
その場所を中央ハブとしてアナウンスすることで、プレイヤーから見つけられるようにできるのだ。

%% The current implementation is \code{metaserver-lite}, a PHP script,
%% which lives at some central place like the Thousand Parsec
%% website. Supporting servers send an HTTP request specifying the update
%% action and containing the type, location (protocol, host, and port),
%% ruleset, number of players, object count, administrator, and other
%% optional information. Server listings expire after a specified timeout
%% (by default, 10 minutes), so servers are expected to update the
%% metaserver periodically.
現在の実装は\code{metaserver-lite}というPHPスクリプトで、
Thousand Parsecのウェブサイトなどいくつかの場所で公開されている。
サポートするサーバーは、HTTPリクエストを送ってupdateアクションを指定し、
型や場所(プロトコル、ホスト、ポート)、ルールセット、プレイヤー数、オブジェクト数、
管理者などの情報を伝える。サーバー一覧の情報は一定期間(デフォルトでは10分)
でタイムアウトとなるので、サーバーは定期的にメタサーバーを更新することが求められる。

%% The script can then, when called with no specified action, be used to
%% embed the list of servers with details into a web site, presenting
%% clickable URLs (typically with the \code{tp://} scheme
%% name). Alternatively, the badge action presents server listings in a
%% compact ``badge'' format.
このスクリプトに何もアクションを指定せずに呼ぶと、
サーバーの一覧とその詳細をウェブサイトに組み込むことができる。
そしてそこに、クリッカブルなURL(通常は\code{tp://}スキームとなる)を含めることができる。
あるいは、badgeアクションを指定すれば、サーバー一覧をコンパクトな「バッジ」形式で表示できる。

%% Clients may issue a request to a metaserver using the get action to
%% obtain a list of available servers. In this case, the metaserver
%% returns one or more \code{Game} frames for each server in the list to
%% the client. In \code{tpclient-pywx}, the resulting list is presented
%% through a server browser in the initial connection window.
クライアントからメタサーバーに対してgetアクションのリクエストを発行すれば、
利用可能なサーバーの一覧を取得できる。このときメタサーバーがクライアントに返すのは、
一覧の各サーバーについての\code{Game}フレームである。
\code{tpclient-pywx}では、この結果一覧を初期接続ウィンドウのサーバーブラウザに表示する。

\end{aosasect2}

%% \begin{aosasect2}{Single-Player Mode}
\begin{aosasect2}{シングルプレイヤーモード}

%% Thousand Parsec is designed from the ground up to support networked
%% multiplayer games. However, there is nothing preventing a player from
%% firing up a local server, connecting a few AI clients, and
%% hyperjumping into a custom single-player universe ready to be
%% conquered. The project defines some standard metadata and
%% functionality to support streamlining this process, making setup as
%% easy as running a GUI wizard or double-clicking a scenario file.
Thousand Parsecは、ネットワーク対応のマルチプレイヤーゲームとして作られたものだ。
しかし別に、ローカルサーバーを立ち上げた一人のプレイヤーがそこに数台のAIクライアントを接続し、
単独でその世界に飛び込んで征服しようとしたっていっこうにかまわない。
そんなときのための標準的なメタデータや機能も用意されており、
GUIのウィザードを実行するかシナリオファイルをダブルクリックするだけで準備できる。

%% At the core of this functionality is an XML DTD specifying the format
%% for metadata regarding the capabilities and properties of each
%% component (e.g., server, AI client, ruleset). Component packages ship
%% with one or more such XML files, and eventually all of this metadata
%% is aggregated into an associative array divided into two major
%% portions: servers and AI clients. Within a server's metadata will
%% typically be found metadata for one or more rulesets---they are found
%% here because even though a ruleset may be implemented for more than
%% one server, some configuration details may differ, so
%% separate metadata is needed in general for each implementation.
%% Each entry for one of these components contains the following information:
この機能の中核となるのが、各コンポーネント(サーバー、AIクライアント、ルールセット)
の機能やプロパティにまつわるメタデータ用のフォーマットを指定したXML DTDである。
コンポーネントのパッケージにはこういったXMLファイルが同梱されており、
最終的にこれらのメタデータがすべて連想配列にとりまとめられる。
この連想配列は大きく二つの部分に分かれている。サーバーとAIクライアントだ。
サーバーのメタデータの中には、一般的にはいくつかのルールセットのメタデータが入っている。
ルールセットの実装は複数のサーバーを対象にしたものだがその細かい設定はサーバーによって異なるかもしれないので、
実装ごとに個別のメタデータが必要になるのだ。
これらのコンポーネントの各エントリには、次の情報が含まれている。

\begin{aosaitemize}

  %% \item Descriptive data, including a short (binary) name, a long
  %% (descriptive) name, and a description.
  \item 説明のデータ。短い名前や長い名前そして説明文など。

  %% \item The installed version of the component, and the earliest
  %% version whose save data is compatible with the installed version.
  \item インストールされているコンポーネントのバージョン、そしてそのバージョンで互換性があるのはどのバージョン以降で作ったセーブデータか。

  %% \item The command string (if applicable) and any forced parameters
  %% passed to it.
  \item 渡すコマンド文字列(もし受け付けているなら)および強制パラメータ。

  %% \item A set of parameters which can be specified by the player.
  \item プレイヤーが設定できるパラメータ群。

\end{aosaitemize}

%% Forced parameters are not player-configurable and are typically
%% options which allow the components to function appropriately for a
%% local, single-player context. The player parameters have their own
%% format indicating such details as the name and description, the data
%% type, default, and range of the value, and the format string to append
%% to the main command string.
強制パラメータはプレイヤーが設定することはできない。
一般的には、コンポーネントがシングルプレイヤーモードに合わせて適切に機能するよう設定されている。
プレイヤーが設定ｄけいるパラメータはそれぞれ独自のフォーマットで、
たとえば名前や説明、データ型、デフォルト、値の範囲、コマンド文字列に付加する書式文字列などを指定する。

%% While specialized cases are possible (e.g., preset game configurations
%% for ruleset-specific clients), the typical process for constructing a
%% single-player game involves selecting a set of compatible
%% components. Selection of the client is implicit, as the player will
%% have already launched one in order to play a game; a well-designed
%% client follows a user-centric workflow to set up the remainder. The
%% next natural choice to make is the ruleset, so the player is presented
%% with a list---at this point, there is no need to bother with server
%% details. In the event that the chosen ruleset is implemented by
%% multiple installed servers (probably a rare condition), the player is
%% prompted to select one; otherwise, the appropriate server is selected
%% automatically. Next, the player is prompted to configure options for
%% the ruleset and server, with sane defaults pulled from the
%% metadata. Finally, if any compatible AI clients are installed, the
%% player is prompted to configure one or more of them to play against.
特殊な場合(そのルールセット固有のクライアント用のプリセット設定でゲームをする場合など)もあり得るが、
一般的なシングルプレイヤーゲームの手順は互換性のあるコンポーネント群を選ぶところから始まる。
クライアントの選択は暗黙のうちに行われる。というのもプレイヤーは既に、
ゲームをプレイするためにひとつのクライアントを立ち上げているからである。
きちんと設計されたクライアントが、ユーザー中心のワークフローに沿って残りを準備する。
次に選ばなければいけないのは当然、ルールセットだ。そこで、ルールセットの一覧をプレイヤーに表示する。
この時点では、サーバーの詳細を気にする必要はない。
選択したルールセットが複数のサーバーで実装されている場合(おそらくめったにないことだろう)は、
そのうちのいずれかを選ぶようプレイヤーに問いかける。
そうでなければ、適切なサーバーが自動的に選ばれる。
次にプレイヤーは、ルールセットとサーバーのオプションを設定するよう指示を受ける。
あらかじめメタデータからのデフォルト値が設定されているものだ。
最後に、もし互換性のあるAIクライアントがインストールされていれば、
それらの対戦相手の設定を行う。

%% With the game so configured, the client launches the local server with
%% appropriate configuration parameters (including the ruleset, its
%% parameters, and any parameters it adds to the server's configuration),
%% using the command string information from the metadata. Once it has
%% verified that the server is running and accepting connections, perhaps
%% using the administration protocol extension discussed previously, it
%% launches each of the specified AI clients similarly, and verifies that
%% they have successfully connected to the game. If all goes well, the
%% client will then connect to the server---just as if it were connecting
%% to an online game---and the player can begin exploring, trading,
%% conquering, and any of a universe of other possibilities.
ゲームの設定をするとともに、クライアントはローカルサーバーを立ち上げる。
メタデータから取得したコマンド文字列の情報を使って、適切なパラメータ
(ルールセットやそのパラメータ、その他サーバーに関する設定項目)
を設定する。サーバーが立ち上がって接続を受け付ける状態になったら、
先ほど説明した管理プロトコルの拡張を使って
AIクライアントも同様に立ち上げる。そして、それらもきちんとゲームに接続できたことを確かめる。
すべてがうまくいけば、クライアントが(オンラインゲームのときと同じように)サーバーに接続し、
プレイヤーはゲームの世界で動き出せるようになる。

%% An alternate---and very important---use for the single-player
%% functionality is the saving and loading of games, and, more or less
%% equivalently, the loading of ready-to-play scenarios. In this case,
%% the save data (probably, though not necessarily, a single file) stores
%% the single-player game configuration data alongside the persistence
%% data for the game itself. Provided all appropriate components in
%% compatible versions are installed on the player's system, launching a
%% saved game or scenario is completely automatic. Scenarios in
%% particular thus provide an attractive one-click entry into a
%% game. Although Thousand Parsec does not currently have a dedicated
%% scenario editor or a client with an edit mode, the concept is to
%% provide some means of crafting the persistence data outside of the
%% normal functioning of the ruleset, and verifying its consistency and
%% compatibility.
シングルプレイヤーモードのもうひとつの(そしてとても重要な)機能は、ゲームをセーブしたりロードしたりできることだ。
そしてそれと同じくらい大切なのが、すぐにプレイできる状態のシナリオを読み込む機能である。
このときのセーブデータ(必須ではないが、おそらくひとつのファイルになるだろう)に格納される内容は、
シングルプレイヤーゲームの設定データやゲーム自体の永続データである。
すべてのコンポーネントについて互換性のあるバージョンがインストールされてさえいれば、
セーブしたゲームやシナリオを自動的に立ち上げることができる。
特にシナリオに関しては、ワンクリックでゲームを始められるような仕組みを提供している。
今のところThousand Parsecには専用のシナリオエディタはないし、
エディットモードつきのクライアントも存在しない。
しかし、何らかの手段を用意して通常のルールセットとの機能とは別に永続データを作れるようにする考えはある。
その一貫性や互換性も検証できるようにするつもりだ。

%% So far, the description of this functionality has been rather
%% abstract. On a more concrete level, the Python client helper library,
%% \code{libtpclient-py}, is currently home to the only full realization
%% of single-player mechanics in the Thousand Parsec project. The library
%% provides the \code{SinglePlayerGame} class, which upon instantiation
%% automatically aggregates all available single-player metadata on the
%% system (naturally, there are certain guidelines as to where the XML
%% files should be installed on a given platform). The object can then be
%% queried by the client for various information on the available
%% components; servers, rulesets, AI clients, and parameters are stored
%% as dictionaries (Python's associative arrays). Following the general
%% game building process outlined above, a typical client might perform
%% the following:
ここまでに説明した内容は、あくまでも抽象レベルのものだ。実装レベルで見ると、
Thousand ParsecプロジェクトのPythonクライアントヘルパーライブラリである\code{libtpclient-py}が
今のところ唯一シングルプレイヤーモードのすべての仕組みを理解できるものである。
このライブラリには\code{SinglePlayerGame}クラスがある。
これは自動的にインスタンス化されてシステム上のすべてのシングルプレイヤー用メタデータを収集する
(当然、システム上のどこにXMLファイルをインストールするかについてはプラットフォームごとにガイドラインがある)。
クライアントからは、利用可能なコンポーネント
(サーバーやルールセット、AIクライアント、そしてPythonの連想配列であるディクショナリに格納されているパラメータなど)
に関するさまざまな情報を問い合わせられるようになる。
先ほど説明したゲームの組み立て手順に照らし合わせると、一般的なクライアントの動きは次のようになる。

\begin{aosaenumerate}

  %% \item Query a list of available rulesets via
  %% \code{SinglePlayerGame.rulesets}, and configure the object with
  %% the chosen ruleset by setting \code{SinglePlayerGame.rname}.
  \item 利用できるルールセットの一覧を\code{SinglePlayerGame.rulesets}
  で問い合わせ、選択したルールセットのオブジェクトを\code{SinglePlayerGame.rname}で設定する。

  %% \item Query a list of servers implementing the ruleset via
  %% \code{SinglePlayerGame.list\_servers\_with\-\_ruleset}, prompt the
  %% user to select one if necessary, and configure the object with the
  %% chosen (or only) server by setting \code{SinglePlayerGame.sname}.
  \item 選択したルールセットを実装するサーバーを\code{SinglePlayerGame.list\_servers\_with\-\_ruleset}
  で問い合わせ、複数存在する場合はその中からユーザーに選ばせる。
  そして、選んだサーバーのオブジェクトを\code{SinglePlayerGame.sname}で設定する。

  %% \item Obtain the set of parameters for the server and ruleset via
  %% \code{SinglePlayerGame.list\_rparams} and
  %% \code{SinglePlayerGame.list\_sparams}, respectively, and prompt
  %% the player to configure them.
  \item そのサーバーとルールセット用のパラメータセットをそれぞれ\code{SinglePlayerGame.list\_rparams}
  \code{SinglePlayerGame.list\_sparams}で取得し、プレイヤーに設定させる。

  %% \item Find available AI clients supporting the ruleset
  %% via \code{SinglePlayerGame.list\_aiclients\_\-with\_ruleset}, and
  %% prompt the player to configure one or more of them using the
  %% parameters obtained via \code{SinglePlayerGame.list\_aiparams}.
  \item そのルールセットに対応しているAIクライアントを\code{SinglePlayerGame.list\_aiclients\_\-with\_ruleset}
  で探し、\code{SinglePlayerGame.list\_aiparams}で取得したパラメータを使ってプレイヤーに設定させる。

  %% \item Launch the game by calling \code{SinglePlayerGame.start},
  %% which will return a TCP/IP port to connect on if successful.
  \item \code{SinglePlayerGame.start}を呼んでゲームを始める。
  これは、成功した場合に接続先のTCP/IPポートを返す。

  %% \item Eventually, end the game (and kill any launched server and AI
  %% client processes) by calling \code{SinglePlayerGame.stop}.
  \item 最終的にゲームを終了させる
  (そして、立ち上がっているサーバーとAIクライアントのプロセスを終了させる)
  には\code{SinglePlayerGame.stop}を呼ぶ。

\end{aosaenumerate}

%% Thousand Parsec's flagship client, \code{tpclient-pywx}, presents a
%% user-friendly wizard which follows such a procedure, initially
%% prompting instead for a saved game or scenario file to load. The
%% user-centric workflow developed for this wizard is an example of good
%% design arising from the open source development process of the
%% project: the developer initially proposed a very different process
%% more closely aligned with how things were working under the hood, but
%% community discussion and some collaborative development produced a
%% result much more usable for the player.
Thousand Parsecのフラッグシップクライアントである\code{tpclient-pywx}
には使いやすいウィザードが組み込まれており、
セーブしたゲームやシナリオファイルを読み込むところからこれらの手順を進めてくれる。
このウィザードに組み込まれたユーザー主導のワークフローはまさに、
オープンソースプロジェクトの開発の成果の一例と言えるだろう。
開発者が最初に用意したのはもっと違う手順で、実際の内部的な動きにより近いものだった。
コミュニティでの議論や共同開発などのおかげで、それがよりユーザーに使いやすいものになったのだ。

%% Finally, saved games and scenarios are currently implemented in
%% practice in \code{tpserver-cpp}, with supporting functionality in
%% \code{libtpclient-py} and an interface in \code{tpclient-pywx}. This
%% is achieved through a persistence module using SQLite, a public domain
%% open source RDBMS which requires no external process and stores
%% databases in a single file. The server is configured, via a forced
%% parameter, to use the SQLite persistence module if it is available,
%% and as usual, the database file (living in a temporary location) is
%% constantly updated throughout the game. When the player opts to save
%% the game, the database file is copied to the specified location, and a
%% special table is added to it containing the single player
%% configuration data. It should be fairly obvious to the reader how this
%% is subsequently loaded.
最後に、保存されたゲームやシナリオについては、現在は
\code{tpserver-cpp}で実装されており、\code{libtpclient-py}
のサポート機能や\code{tpclient-pywx}のインターフェイスを使っている。
SQLiteを使う永続化モジュールでこれを実現した。SQLiteは
パブリックドメインなオープンソースのRDBMSで、外部のプロセスを必要としないし
データベースを単一のファイルとして格納できる。
サーバーの設定を強制パラメータ経由で行うときには、もし使えればSQLiteの永続化モジュールを利用する。
そして、データベースのファイル(テンポラリディレクトリにある)はゲームの実行中常に更新される。
プレイヤーがゲームのセーブをするときにはデータベースファイルを指定の場所にコピーし、
シングルプレイヤーの設定データを格納するための特別なテーブルを追加する。
これをあとでどうやって読み込むのかは、リーダーがよく知っているはずだ。

\end{aosasect2}

\end{aosasect1}

%% \begin{aosasect1}{Lessons Learned}
\begin{aosasect1}{教訓}

%% The creation and growth of the extensive Thousand Parsec framework has
%% allowed the developers plenty of opportunity to look back and assess
%% the design decisions that were made along the way. The original core
%% developers (Tim Ansell and Lee Begg) built the original framework from
%% scratch and have shared with us some suggestions on starting a similar
%% project.
大規模なThousand Parsecフレームワークを作って成長させていく過程を振り返ると、
開発者達が設計に関する決断を下す場面が数多く存在した。
最初のコアデベロッパー(Tim AnsellとLee Begg)はフレームワークをスクラッチから構築し、
私たちが同様のプロジェクトを始めるにあたっていろんな提案をしてくれた。

%% \begin{aosasect2}{What Worked}
\begin{aosasect2}{うまくいったこと}

%% A major key to the development of Thousand Parsec was the decision to
%% define and build a subset of the framework, followed by the
%% implementation. This iterative and incremental design process allowed
%% the framework to grow organically, with new features added
%% seamlessly. This led directly to the decision to version the
%% Thousand Parsec protocol, which is credited with a number of major
%% successes of the framework. Versioning the protocol allowed the
%% framework to grow over time, enabling new methods of gameplay along
%% the way.
Thousand Parsecの開発における大切なポイントは、
フレームワークのサブセットを定義および構築してからそれを実装すると決めたことだった。
イテレーティブかつインクリメンタルな設計プロセスを使ったことでフレームワークは組織的に成長し、
新機能もシームレスに追加できるようになった。その流れでThousand Parsecプロトコルも
バージョンで管理することになり、これもフレームワークの成功に大きく貢献した。
プロトコルをバージョンで管理したおかげで、フレームワークを日々成長させてゲーム用のメソッドもどんどん追加できるようになったのだ。

%% When developing such an expansive framework, it is important to have a
%% very short-term approach for goals and iterations. Short iterations, on the order of weeks for a minor release,
%% allowed the project to move forward quickly with immediate returns
%% along the way. Another success of the
%% implementation was the client-server model, which allowed for the
%% clients to be developed away from any game logic. The separation of
%% game logic from client software was important to the overall success
%% of Thousand Parsec.
広範囲の及ぶフレームワークを開発するときに重要なのは、
イテレーションごとの短期的なゴールを定めてそこに向かっていくことだ。
数週間レベルの短いイテレーションでマイナーリリースをするようにすると、
プロジェクトの進み具合も速くなるし、すぐに反応が得られるようになる。
もうひとつうまくいったことがあって、それは実装にクライアント・サーバーモデルを採用したことだ。
そのおかげで、クライアントの開発をゲームのロジックとは切り離して考えられるようになった。
ゲームのロジックとクライアントソフトウェアを分離したことがThousand Parsecの大成功につながった。

\end{aosasect2}

%% \begin{aosasect2}{What Didn't Work}
\begin{aosasect2}{うまくいかなかったこと}

%% A major downfall of the Thousand Parsec framework was the decision to
%% use a binary protocol. As you can imagine, debugging a binary protocol
%% is not a fun task and this has lead to many prolonged debugging
%% sessions. We would highly recommend that nobody take this path in the
%% future. The protocol has also grown to have too much flexibility; when
%% creating a protocol, it is important to implement only the basic
%% features that are required.
Thousand Parsecフレームワークの最大の失敗は、バイナリプロトコルを使ったことだ。
だいたい想像できるだろうが、バイナリプロトコルのデバッグは決して楽しい作業じゃない。
デバッグにかかる時間もどんどん伸びてしまう。
これから何かを実装しようとする人たちには、バイナリプロトコルは使わないようお勧めしたい。
さらに、このプロトコルはどんどん成長して、必要以上に柔軟性を持ちすぎるようになってしまった。
何かのプロトコルを作る際には、必要最小限の基本的な機能だけを実装することが大切だ。

%% Our iterations have at times grown too large. When managing such a
%% large framework on an open source development schedule, it is
%% important to have a small subset of added features in each iteration
%% to keep development flowing.
私たちの開発のイテレーションは、たまに長くなりすぎることもあった。
巨大なフレームワークの開発をオープンソースの開発スケジュールで管理するときに大切なのは、
追加された機能の小さなサブセットを各イテレーションで扱うようにして、開発をうまく流れるようにしていくことだ。

\end{aosasect2}

%% \begin{aosasect2}{Conclusion}
\begin{aosasect2}{結論}

%% Like a construction skiff inspecting the skeletal hull of a massive
%% prototype battleship in an orbital construction yard, we have passed
%% over the various details of the architecture of Thousand Parsec. While
%% the general design criteria of flexibility and extensibility have been
%% in the minds of the developers from the very beginning, it is evident
%% to us, looking at the history of the framework, that only an open
%% source ecosystem, teeming with fresh ideas and points of view, could
%% have produced the sheer volume of possibilities while remaining
%% functional and cohesive. It is a singularly ambitious project, and as
%% with many of its peers on the open source landscape, much remains to
%% be done; it is our hope and expectation that over time, Thousand
%% Parsec will continue to evolve and expand its capabilities while new
%% and ever more complex games are developed upon it. After all, a
%% journey of a thousand parsecs begins with a single step.
軌道上の造船所で小舟に乗って巨大戦艦のプロトタイプの船体を調査するがごとく、
本章ではThousand Parsecのアーキテクチャの詳細をいろいろ見てきた。
全体的な設計指針として、柔軟性と拡張性を重視するということが最初からずっと開発者達の念頭にあった。
ここまでの流れを振り返っても明らかなように、オープンソースのエコシステムに身を置いて
仲間たちのいろいろなアイデアや観点を取り入れたからこそこのフレームワークができあがったのだ。
さまざまな可能性を秘めつつ、機能的にも優れていてきちんとまとまっている。
これは非常に野心的なプロジェクトなので、オープンソースの世界の仲間たちと同様に、私たちにもまだまだやるべきことが残っている。
Thousand Parsecは今後も成長を続けるだろうし、その機能を拡張し続けるだろう。
それを使って、新たなゲーム・より複雑なゲームも開発されるはずだ。
結局のところ、1000パーセクの旅と言ってもはじめの一歩は小さなものなんだ。

\end{aosasect2}

\end{aosasect1}

\end{aosachapter}
